什么是core dump

程序由于收到某些特定的signal之后终止了，终止过程中会产生core文件，

core文件中包含了程序终止时的内存的状态,这个过程就是core dump。

使用gdb工具结合可执行程序和debug symbol就能够查训到只要是类unix系统，都有这个机制。

具体哪些signal会时程序产生 core dump文件，这个可以通过man 7 signal查看。

coredump文件的存储位置

注意： mac系统是存储在固定的/cores/ 目录下的

core文件默认的存储位置与对应的可执行程序在同一目录下，文件名是core，大家可以通过下面的命令看到core文件的存在位置：

cat /proc/sys/kernel/core_pattern

缺省值是core

注意：这里是指在进程当前工作目录的下创建。通常与程序在相同的路径下, 程序中可以调用chdir函数，来改变当前工作目录。

这时core文件创建在chdir指定的路径下。

通过下面的命令可以更改coredump文件的存储位置，若你希望把core文件生成到/data/coredump/core目录下：

echo “/data/coredump/core”> /proc/sys/kernel/core_pattern

注意，这里当前用户必须具有对/proc/sys/kernel/core_pattern的写权限。

缺省情况下，内核在coredump时所产生的core文件放在与该程序相同的目录中，并且文件名固定为core。很显然，如果有多个程序产生core文件，或者同一个程序多次崩溃，就会重复覆盖同一个core文件，因此我们有必要对不同程序生成的core文件进行分别命名。

我们通过修改kernel的参数，可以指定内核所生成的coredump文件的文件名。例如，使用下面的命令使kernel生成名字为core.filename.pid格式的core dump文件：

echo “/data/coredump/core.%e.%p” >/proc/sys/kernel/core_pattern

这样配置后，产生的core文件中将带有崩溃的程序名、以及它的进程ID。上面的%e和%p会被替换成程序文件名以及进程ID。

如果在上述文件名中包含目录分隔符“/”，那么所生成的core文件将会被放到指定的目录中。

需要说明的是，在内核中还有一个与coredump相关的设置，就是/proc/sys/kernel/core_uses_pid。

如果这个文件的内容被配置成1，那么即使core_pattern中没有设置%p，最后生成的core dump文件名仍会加上进程ID。

由于core文件本身就是程序的内存的使用的一个表现，上面的方式也没有提供方法来合理的存储这些core文件，打开了core dump功能的话，磁盘空间很快就会没有了，

所以linux 2.6.19以后引入了管道符号”|”, core dump的内容会通过管道输入到你自己的core dump处理程序，你可以对core dump的内容进行二次处理，有效的减小系统存储core文件所需要的空间

如何判断一个文件是coredump文件？

在类unix系统下，coredump文件本身主要的格式也是ELF格式，因此，我们可以通过readelf命令进行判断。

readelf -h coreELF Header:Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00Class: ELF64Data: 2's complement, little endianVersion: 1 (current)OS/ABI: UNIX - System VABI Version: 0Type: CORE (Core file)Machine: Advanced Micro Devices X86-64Version: 0x1Entry point address: 0x0Start of program headers: 64 (bytes into file)Start of section headers: 0 (bytes into file)Flags: 0x0Size of this header: 64 (bytes)Size of program headers: 56 (bytes)Number of program headers: 25Size of section headers: 0 (bytes)Number of section headers: 0Section header string table index: 0

注意：

Mac下可以使用 otool 工具查看

otool -hv /cores/core.79119/cores/core.79119:Mach headermagic cputype cpusubtype caps filetype ncmds sizeofcmds flagsMH_MAGIC_64 X86_64 ALL 0x00 CORE 56 5416 0x00000000

可以看到ELF文件头的Type字段的类型是：CORE (Core file)

当然也可以通过简单的file命令进行快速判断：

file corecore: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from './a.out'

file /cores/core.79119/cores/core.79119: Mach-O 64-bit core x86_64

 

产生coredum的条件

1， 产生coredump的条件，首先需要确认当前会话的ulimit –c，若为0，则不会产生对应的coredump，需要进行修改和设置。

ulimit -c unlimited (可以产生coredump且不受大小限制)

若想甚至对应的字符大小，则可以指定：

ulimit –c [size]

可以看出，这里的size的单位是blocks,一般1block=512bytes

这里值设定的太小的话决不能生成core dump文件，或者core dump 文件被截断了，这样会影响问题的调查

最理想方式就是设定成程序使用的最大内存数，无法预估的话，推荐设定为ulimited.

当前设置的ulimit只对当前会话有效，若想系统均有效，则需要进行如下设置：

＊ 在/etc/profile中加入以下一行，这将允许生成coredump文件

ulimit -c unlimited

＊在rc.local中加入以下一行，这将使程序崩溃时生成的coredump文件位于/data/coredump/目录下:

echo /data/coredump/core.%e.%p> /proc/sys/kernel/core_pattern

注意rc.local在不同的环境，存储的目录可能不同，suse下可能在/etc/rc.d/rc.local

2， 当前用户，即执行对应程序的用户具有对写入core目录的写权限以及有足够的空间。

3， 几种不会产生core文件的情况说明：

The core file will not be generated if

(a) the process was set-user-ID and the current user is not the owner of the program file, or

(b) the process was set-group-ID and the current user is not the group owner of the file,

(c) the user does not have permission to write in the current working directory,

(d) the file already exists and the user does not have permission to write to it, or

(e) the file is too big (recall the RLIMIT_CORE limit in Section 7.11). The permissions of the core file (assuming that the file doesn't already exist) are usually user-read and user-write, although Mac OS X sets only user-read.

注意: 如果设定为pipe方式的话，core dump 将无视ulimit的值的设定