linux coredump相关设置与说明

目录

coredump背景

coredump原理

系统级别的coredump设置

是否产生coredump

coredump位置以及命名

进程级别的coredump设置

可执行文件是否去掉符号表

coredump_filter

---

coredump背景

在linux后台开发过程中可能一不小心出现访问非法内存而产生段错误，面对段错误我们有时候可以通过打印定位，但那样比较慢，我们可以利用linux提供了一种方法，当程序奔溃时内核会保存程序运行的堆栈信息到一个coredump文件，我们可以通过gdb调试这个coredump文件可以知道程序死之前调用了哪个函数。

coredump原理

应用程序在运行过程中由于各种异常或者bug导致退出，在满足一定条件下产生一个core文件。

通常core文件包含了程序运行时内存、寄存器状态、堆栈指针、内存管理信息以及函数调用堆栈信息。

core就是程序当前工作转改存储生成的一个文件，通过工具分析这个文件，可以定位到程序异常退出的时候对应的堆栈调用等信息，找出问题点并解决。

当程序发生内存越界访问等行为时，会触发OS的保护机制，此时OS会产生一个信号(signal)发送给对应的进程。当进程从内核态到用户态切换时，该进程会处理这个信号。此类信号（比如SEGV）的默认处理行为生成一个coredump文件。

这里会涉及以下几个问题： 
1. 保存的core文件在什么地方？ 
2. core文件，具体会把进程地址空间的哪些内容保存下来？ 
3. 如何控制core文件的大小？ 
4. 如果在处理信号的时候，又产生了新的同类信号，该如何处理？ 
5. 处理信号的代码，是运行在用户态还是内核态？ 
6. 在一个多线程的程序中，是由哪个线程在处理这个信号？

 

系统级别的coredump设置

是否产生coredump

通过 ulimit -c 查看当前系统是否支持coredump。如果为0，则表示coredump被关闭。

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

ulimit –c [size] 可以看出，

这里的size的单位是blocks,一般1block=512bytes
如： ulimit –c 4 (注意，这里的size如果太小，则可能不会产生对应的core文件，笔者设置过ulimit –c 1的时候，系统并不生成core文件，并尝试了1，2，3均无法产生core，至少需要4才生成core文件)

但当前设置的ulimit只对当前会话有效，若想系统均有效，则需要进行如下设置：
在/etc/profile中加入以下一行，这将允许生成coredump文件

ulimit-c unlimited  

在rc.local中加入以下一行，这将使程序崩溃时生成的coredump文件位于/data/coredump/目录下: 
echo /data/coredump/core.%e.%p> /proc/sys/kernel/core_pattern

 

coredump位置以及命名

coredump文件默认存储位置与可执行文件在同一目录下，大家可以通过下面的命令看到core文件的存在位置： cat /proc/sys/kernel/core_pattern 缺省值是core ；

注意：这里是指在进程当前工作目录的下创建。通常与程序在相同的路径下。但如果程序中调用了chdir函数，则有可能改变了当前工作目录。这时core文件创建在chdir指定的路径下。有好多程序崩溃了，我们却找不到core文件放在什么位置。和chdir函数就有关系。当然程序崩溃了不一定都产生 core文件。

缺省情况下，内核在coredump时所产生的core文件放在与该程序相同的目录中，并且文件名固定为core。

很显然，如果有多个程序产生core文件，或者同一个程序多次崩溃，就会重复覆盖同一个core文件，因此我们有必要对不同程序生成的core文件进行分别命名。

可以通过/proc/sys/kernel/core_pattern进行设置。

%p  出Core进程的PID
%u  出Core进程的UID
%s  造成Core的signal号
%t  出Core的时间，从1970-01-0100:00:00开始的秒数
%e  出Core进程对应的可执行文件名

比如:
# cat /proc/sys/kernel/core_pattern
/data/coredump/core-%t-%u-%g-%s-%p-%e

将 coredump 文件 放入到 /data/coredump/ 目录下；

进程级别的coredump设置

可执行文件是否去掉符号表

开启coredump功能编译程序时不能通过trip去掉程序连接的符号表信息，不然通过gdb调试时连接不要符号表。

通过 file 命令查看, 如下所示：

# file keepalived
keepalived: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=057a40f6d7cab79d01f0db1531e34cba55fe660f, not stripped

coredump_filter

coredump是抓取进程空间内的内存并保存到文件上,并不是所有内存都需要保存的；

你可以通过设置/proc/$pid/coredump_filter参数过滤,只抓取部分内存。

该参数是一个值,每个bit位都有对应的含义用来表示是否抓取这部分内：

man core可以查看到如下内容：

       Since kernel 2.6.23, the Linux-specific /proc/PID/coredump_filter file can be used to control which memory segments are written to the core dump file in the event that a core dump is performed for the process with
       the corresponding process ID.

       The  value in the file is a bit mask of memory mapping types (see mmap(2)).  If a bit is set in the mask, then memory mappings of the corresponding type are dumped; otherwise they are not dumped.  The bits in this
       file have the following meanings:

           bit 0  Dump anonymous private mappings.
           bit 1  Dump anonymous shared mappings.
           bit 2  Dump file-backed private mappings.
           bit 3  Dump file-backed shared mappings.
           bit 4 (since Linux 2.6.24)
                  Dump ELF headers.
           bit 5 (since Linux 2.6.28)
                  Dump private huge pages.
           bit 6 (since Linux 2.6.28)
                  Dump shared huge pages.

coredump_filter的默认值是0x33，也即发生coredump时会将所有anonymous内存、ELF头页面、hugetlb private memory内容保存。