Linux 下如何产生core文件（core dump设置）

转自：https://blog.csdn.net/star_xiong/article/details/43529637

　　

　　今天在Linux下调试C程序时，出现段错误，习惯性的ls下当前目录，发现没有生成core文件。惊讶了一下，怎么回事？之前都会产生的啊，难不成是程序的问题？后来同事提醒是否是系统没有打开生成core dump的设置。

还真是系统设置问题，个人ubuntu14.04是新装的，以前没有进行过core dump的相关配置，别急！咱们来看看怎么对linux系统设置当程序出现段错误时产生core文件：

一、先用#ulimit -a能够查看系统core文件的大小限制（第一行），core文件大小设置为0, 即没有打开core dump设置；

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) unlimited

二、接下来使用#ulimit -c [kbytes]能够设置系统容许生成的core文件大小；
ulimit -c 0 不产生core文件
ulimit -c 100 设置core文件最大为100k
ulimit -c unlimited 不限制core文件大小

执行#ulimit -c unlimited，而后#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

此时，core dump设置打开了，再执行程序出现段错误时，在当前工做目录下产生了core文件，而后咱们就能够用gdb调试core文件了。

 例如：

#gdb ./test core.2065

注：Linux下的C程序经常会由于内存访问错误等缘由形成segment fault(段错误)，此时若是系统core dump功能是打开的，那么将会有内存映像转储到硬盘上来，以后能够用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 -c 1073741824

  (可是，若将产生的转储文件大小大于该数字时，将不会产生转储文件)

或者

　　ulimit -c unlimited

这样重启机器后生效了。 或者， 使用source命令使之立刻生效。

 　　#source /etc/profile

3、指定内核转储的文件名和目录

        修改完内核转储设置后，当程序core dump后发现确实在本地目录产生了core文件，可是若是程序屡次core dump时，core文件会被覆盖，缘由是每次core dump后生成的文件名默认都叫core，接下来就分享下若是想在每次core dum时产生的core文件都带上进程号怎么操做，或者你想把内核转储文件保存到其余目录怎么办？

一、core dump文件名自动加上进程ID

    #echo 1 > /proc/sys/kernel/core_uses_pid

最后生成的core dump文件名会加上进程ID.

二、另外能够经过修改kernel的参数，指定内核转储所生成的core文件的路径和文件名。

       能够经过在/etc/sysctl.conf文件中，对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，最后生成的core dump文件名仍会加上进程ID。

这里%e, %p分别表示：

%c 转储文件的大小上限

%e 所dump的文件名

%g 所dump的进程的实际组ID

%h 主机名

%p 所dump的进程PID

%s 致使本次coredump的信号

%t 转储时刻(由1970年1月1日起计的秒数)

%u 所dump进程的实际用户ID

可使用如下命令，使修改结果立刻生效。

#sysctl –p /etc/sysctl.conf

请在/var目录下先创建core文件夹，而后执行a.out程序，就会在/var/core/下产生以指定格式命名的内核转储文件。查看转储文件的状况：

#ls /var/core

core_a.out_2456

更详细的内容或手动强制某个进程产生core dump的方法见连接：http://blog.csdn.net/wj_j2ee/article/details/7161586

帮助连接：http://www.cppblog.com/API/archive/2012/10/22/193644.html