明天在Linux下调试C程序时，出现段错误，习惯性的ls下当前目录linux 不生成core文件，发觉没有生成core文件。震惊了一下，如何回事？曾经就会形成的啊，难不成是程序的问题？后来朋友提醒是不是系统没有打开生成coredump的设置。
还真是系统设置问题，我的ubuntu14.04是新装的，之前没有进行过coredump的相关配置，别急！我们来瞧瞧如何对linux系统设置当程序出现段错误时形成core文件：
1、先用#ulimit-a可以查看系统core文件的大小限制（第一行），core文件大小设置为0,即没有打开coredump设置；
root@XZX:~/cnnic/project/dnsx/dnsX# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 46621
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 46621
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited2、接出来使用#ulimit-c[kbytes]可以设置系统容许生成的core文件大小；
ulimit-c0不形成core文件
ulimit-c100设置core文件最大为100k
ulimit-cunlimited不限制core文件大小
执行#ulimit-cunlimited，之后#ulimit-a查看结果如下（第一行）：
root@XZX:~/cnnic/project/dnsx/dnsX# ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 46621
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 46621
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
此时，coredump设置打开了，再执行程序出现段错误时，在当前工作目录下形成了core文件，之后我们就可以用gdb调试core文件了。
比如：
#gdb./testcore.2065
注：Linux下的C程序往往会由于显存访问错误等诱因引起segmentfault(段错误)，此时若果系统coredump功能是打开的，这么将会有显存映像轮询到硬碟上来，然后可以用gdb对core文件进行剖析，还原系统发生段错误时刻的堆栈情况。这对于我们发觉程序bug很有帮助。
好多系统默认的core文件大小都是0，我们可以通过在shell的启动脚本/etc/bashrc或则~/.bashrc等地方来加入ulimit-c命令来指定core文件大小，进而确保core文件才能生成。
除此之外，还可以在/proc/sys/kernel/core_pattern里设置core文件的文件模特板，详情请看core的官方man指南。
须要说明的是：上述方式只是在当前shell中生效,重启以后，就不再有效了。永久生效的办法是如下：
永久生效办法：
#vi/etc/profile之后，在profile中添加：
ulimit-c1073741824
(然而，若将形成的存贮文件大小小于该数字时，将不会形成存贮文件)
或则
ulimit-cunlimited
这样重启机器后生效了。或则，使用source命令使之马上生效。
#source/etc/profile
三、指定内核轮询的文件名和目录
更改完内核轮询设置后，当程序coredump后发觉确实在本地目录形成了core文件，而且假如程序多次coredump时，core文件会被覆盖，缘由是每次coredump后生成的文件名默认都叫core，接出来就分享下假如想在每次coredum时形成的core文件都带上进程号如何操作，或则你想把内核存贮文件保存到其他目录如何办？
1、coredump文件名手动加上进程ID
#echo1>/proc/sys/kernel/core_uses_pid
最后生成的coredump文件名会加上进程ID.
2、另外可以通过更改kernel的参数linux deepin，指定内核轮询所生成的core文件的路径和文件名。
可以通过在/etc/sysctl.conf文件中linux 不生成core文件，对sysctl变量kernel.core_pattern的设置。
#vim/etc/sysctl.conf之后，在sysctl.conf文件中添加下边两句话：
kernel.core_pattern=/var/core/core_%e_%p
kernel.core_uses_pid=0
保存后退出。
注：假如/proc/sys/kernel/core_uses_pid这个文件的内容被配置成1，虽然core_pattern中没有设置%p，最后生成的coredump文件名仍会加上进程ID。
这儿%e,%p分别表示：
%c轮询文件的大小上限
%e所dump的文件名
%g所dump的进程的实际组ID
%h主机名
%p所dump的进程PID
%s造成本次coredump的讯号
%t轮询时刻(由1970年1月1日起计的秒数)
%u所dump进程的实际用户ID
可以使用以下命令linux web服务器，使更改结果马上生效。
#sysctl–p/etc/sysctl.conf
请在/var目录下先构建core文件夹，之后执行a.out程序，都会在/var/core/下形成以指定格式命名的内核轮询文件。查看轮询文件的情况：
#ls/var/core
core_a.out_2456
更详尽的内容或自动强制某个进程形成coredump的方式见链接：
帮助链接：
