生成 core dump 文件及应用

beyes

在写 Linux 程序时，经常会遇到“段错误”(segmentation fault) 这样的问题。如果程序比较大，那么如果用 gdb 调试可能显得比较吃力。这时可以用 core dump 文件来进行分析。

那什么是 core dump 文件呢？
core dump 文件就是在程序发生错误时，由操作系统把程序错误时的相应内容 dump 出来，然后存储在一个文件中，这个文件就是当时的内存映像，也就是 core dump　文件。

造成“段错误”产生的原因经常是因为指针的乱用。比如下面这个测试程序：

#include <stdio.h>

int main()
{
        char *p = "hello world";

        *(p+1) = 'X';

        printf ("%s\n", p);


        return (0);
}

在上面的程序中，hello world 字符串在编译时就会被分配到 .rodata 区域，相当于属于 const 类型，是不能进行修改的。然后在程序里，却用指针进行了更改，那么这个程序在运行起来，就会产生段错误：

# ./coredump_test.exe
段错误 (core dumped)

我的系统是 CentOS 5.3 ，是 RedHat 5.3 的编译版，而 RedHat 在默认情况下是不错产生 core dumped 文件的。而上面，在括号里提示 core dumped ，则表示已经产生了 core dumped 文件。使能产生 core dumped 文件的方法是：

ulimit -S -c unlimited > /dev/null 2>&1

关于 ulimit 命令的用法见：http://www.groad.net/bbs/read.php?tid-1471.html

使用 gdb 与 core dumped　来定位错误

当运行程序出错后，会产生 core dumped 文件，此时可用 gdb 和 core dumped 配合来定位程序的错误，使用方法是：

gdb 可执行文件 core_dumped文件

像上面的程序，生成的可执行文件名叫做 coredump_test.exe ，现在运行它出错了，可以在与程序同一个目录下观察到生成的 core dumped 文件：core.10852 。这里 core.10852 中的 10852 是当时程序运行的 pid 值。关于如何控制生成 core dumped　文件见：http://www.groad.net/bbs/read.php?tid-1470.html

现在进行调试：

gdb coredump_test.exe core.10852

出现提示信息：

[root@localhost ~]# gdb coredump_test.exe core.10852
GNU gdb Fedora (6.8-27.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...

warning: core file may not match specified executable file.

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./coredump_test.exe'.
Program terminated with signal 11, Segmentation fault.
[New process 10852]
#0  0x080483a2 in main () at coredump_test.c:7
7               *(p+1) = 'X';

由上面的信息可见，已经定位出了出错的行！这里，就是乱用了指针去修改固化字符串的结果，这是不允许的！

注意，想让 core dumped　可以正常工作，在编译可执行文件时，必须用 -g　调试选项来编译生成文件。

beyes

当我的应用程序崩溃或出现段错误的时候，如何产生core文件?
解决方法:

在红帽企业版Linux上默认是不产生core文件。这个限制是在/etc/profile里面设置的:

ulimit -S -c 0 > /dev/null 2>1

有几种方法可以让系统产生core文件。第一个方法是修改/etc/profile里面的ulimit命令，如下:

ulimit -S -c unlimited > /dev/null 2>1

上面的设置允许系统上的所有用户产生没有文件大小限制的core文件。

如果只需要对部分用户或组开放产生core文件的权限，需要编辑/etc/security/limits.conf文件。例如，所有在"devel"组里面的用户可以产生core文件:


#<domain> <type>  <item>  <value>
@devel  soft core <value>

<value>是core文件的最大块大小。在/etc/security/limits.conf文件里面有配置参数的详细说明。提示，如果想通过limits.conf里面的设置来控制用户是否可以产生core文件，需要把/etc/profile里面的ulimits设置注释掉:


# No core files by default
# ulimit -S -c 0 > /dev/null 2>1

如果应用是通过daemon命令来启动的，编辑/etc/init.d/functions，注释掉ulimit的设置或改变这行:

ulimit -S -c 0 >/dev/null 2>1

通过上面的设置，应用程序应该可以产生core文件。如果不能产生core文件，请检查您的应用程序是否拥有正确的uid，在程序执行的时候是否有使用setuid改变程序的uid。 在红帽企业Linux 3上面， 可以通过下面的命令允许使用setuid的应用程序产生core文件:

echo 1 > /proc/sys/kernel/core_setuid_ok

另外，您也可以在应用程序中添加下面的代码来实现:

prctl(PR_SET_DUMPABLE, 1);

默认情况下，core文件会创建在应用程序的工作目录下。如果您想指定core文件存放的目录，您可以执行以下命令(用您要保存的路径替换/tmp):

echo "/tmp" > /proc/sys/kernel/core_pattern

beyes

当程序接收到以下信号时会产生 core 文件：

SIGABRT ：异常终止(abort)时发出的信号
说明：
调用abort函数时产生此信号。进程异常终止。


SIGBUS ：硬件发生故障时发出的信号
说明：
指示一个实现定义的硬件故障。

SIGFPE ：算术异常时发出的信号
说明：
此信号表示一个算术运算异常，例如除以0，浮点溢出等。

SIGILL ：遇到非法硬件指令时发出的信号
说明：
此信号指示进程已执行一条非法硬件指令。4.3BSD由abort函数产生此信号。现在 abort() 函数用来生成 SIGABRT 信号。

SIGIOT ：硬件故障时发出的信号
说明：
IOT这个名字来自于PDP-11对于 输入/输出 TRAP(input/output TRAP)指令的缩写。系统V的早期版本，由abort函数产生此信号。SIGABRT现在被用于此。

SIGQUIT ：终端退出时发出的信号
说明：
当用户在终端上按退出键（一般采用Ctrl-\\）时，产生此信号，并送至前台进程组中的所有进程。此信号不仅终止前台进程组（如SIGINT所做的那样），同时产生一个core文件。

SIGSEGV ：无效存储访问发出的信号
说明：
进程进行了一次无效的存储访问。字SEGV表示“段违例（segmentation violation）”。

SIGSYS ：无效的系统调用时发出的信号
说明：
进行了一个无效的系统调用。由于某种未知原因，进程执行了一条系统调用指令，但其指示系统调用类型的参数却是无效的。

SIGTRAP ：硬件故障时发出的信号
说明：
此信号名来自于 PDP-11 的TRAP指令。

SIGXCPU ：超过CPU限制(setrlimit)时发出的信号
说明：
SVR4 和 4.3+BSD 支持资源限制的概念。如果进程超过了其软 CPU 时间限制，则产生此信号。XCPU 是 "exceeded CPU time“ 的缩写。

SIGXFSZ ：超过文件长度限制(setrlimit)时发出的信号
说明：
如果进程超过了其软文件长度限制时发出此信号。

beyes

core_uses_pid 和 core_pattern 文件都位于 /proc/sys/kernel/ 下，设置此目录下的文件可通过 sysctl 命令，或直接 echo 一个值给它们。

/proc/sys/kernel/core_uses_pid 文件可以控制 core 文件的文件名中是否添加 pid 作为扩展。该文件内容默认为 1，表示添加 pid 作为扩展名，生成的core文件格式为core.xxxx，后面的 xxxx 为该进程运行时的 pid 号；为 0 则表示生成的core文件同一命名为 core。

/proc/sys/kernel/core_pattern  文件用来控制 core 文件保存位置和文件名格式。cat 查看该文件时输出(Fedora15)：

[root@localhost syscall]#  cat /proc/sys/kernel/core_pattern
|/usr/libexec/abrt-hook-ccpp /var/spool/abrt %s %c %p %u %g %t %h %e 636f726500

上面带有 % 的参数分别表示：

%p - insert pid into filename 添加pid
%u - insert current uid into filename 添加当前uid
%g - insert current gid into filename 添加当前gid
%s - insert signal that caused the coredump into the filename 添加导致产生core的信号
%t - insert UNIX time that the coredump occurred into filename 添加core文件生成时的unix时间
%h - insert hostname where the coredump happened into filename 添加主机名
%e - insert coredumping executable name into filename 添加命令名

比如：

[root@localhost syscall]# ./abort
hello world
Aborted (core dumped)
[root@localhost syscall]# ls /tmp/core
core.3438

上面，我们设置了生成的 core dump 文件是以 core.xxxx 这种形式命名的，另外它会在 /tmp/core 目录下存放此 core dump 文件。这里需要注意的是，如果 /tmp/core 目录原先不存在，那么生成的 core dump 文件就无处存放，所以要先确定设置的目录是事先存在的。另外，如果想这种设置在计算机重启后生效，需要将 core_pattern 的设置写入 /etc/sysctl.conf 文件中。

jzesx

的确好帖子，推荐加精华