使用 GDB 调试 core dump 文件

上次有个客户的设备出现了引擎挂掉的现象，其中有一次挂掉之后自己没有起来，通过查看日志得知是出现了段错误，但是由于日志提供的信息太少了，我使用反汇编跟踪了 2 天，终于找到段错误的地方，但是仍然没有找到具体是哪句出现段错误，还是不能解决问题。于是，决定在发布的 release 打开 core dump 功能，当出现段错误之后会将一些重要的信息输出到 core 文件。
        于是上网找了很多资料，其中有一遍写的比较好，我就搬过来： http://www.ms2006.com/archives/151

core dump在应用crash掉之后对问题的诊断是很有帮助的。而在默认安装的时候core dump是关闭状态的。
问题一：如何查看系统是否打开了core dump
使用【ulimit -c】查看core dump是否打开。如果结果为0，则表示此功能处于关闭状态，不会生成core文件。
问题二：如何打开core dump
方法一：命令行方式【ulimit -c 1024】，在这个例子中打开了core dump 同时限制文件大小为1024k，现在的程序占用内存都比较凶猛，以前写C程序需要计算内存的时代已经过去了。如果不加限制，可能一个core文件，几个G就出去了～，当然没有限制的方式还是有的【ulimit -c unlimited】
方法二：配置profile文件，打开/etc/profile文件，在里面可以找到【ulimit -S -c 0 > /dev/null 2>&1】，将它改成【ulimit -S -c unlimited > /dev/null 2>&1】
方法三：修改/etc/security/limits.conf文件，添加【* soft core 0】，这个方法可以针对指定用户或用户组打开core dump【user soft core 0或@group soft core 0】。不过要使用这个方法一定要将方法二提到的那行注释掉，不可同时存在
问题三：如何查看core文件的保存路径和文件名格式
默认情况下，在打开core后，如果应用发生crash，那么会在应用所在位置，产生一个core.【应用pid】的文件，文件名的可读性不高，管理也不方便。
查看正在使用的core文件路径和格式【more /proc/sys/kernel/core_pattern】
后面自动添加pid的配置是在【more /proc/sys/kernel/core_uses_pid】里面配置的，如果为1就是自动添加
问题四：如何修改core文件的保存路径和文件名格式
修改/etc/sysctl.conf文件【vi /etc/sysctl.conf】，添加需要保存的路径【kernel.core_pattern = /tmp/corefile/core.%e.%t】，需要注意的是该路径必须应用有写的权限，不然core文件是不会生成的。再执行命令【sysctl -p】即可生效。关于core_users_pid默认在sysctl文件里面已经存在，不需要更改，pid还是很重要的信息。
附上core文件支持的格式列表：
    %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 【应用的名字】
问题五：如何知道core的配置已经生效
这里通过别人提供的一个例子来实现
编辑一个文件：main.c

#include int div(int i,int j) {     return i / j; } int main() {        int i =2;        int j =0;     printf("%d ",div(i, j));      return 0; }

该程序故意实现以零作为除数的错误，用gcc –g main.c –o main进行编译，然后./main执行，不可避免的程序要down掉，然后就可以到配置的core文件的位置查找，如果存在，说明配置已经生效了～

==============================================================================

        以上讲的是系统的全局配置，如果我们只是想在我们的代码中打开 core dump，该如何配置呢？其实很简单，只需要在代码初始化的时候设置好就行了，具体代码如下：
#include    

struct rlimit new_lim;
new_lim.rlim_max = RLIM_INFINITY;
new_lim.rlim_cur = RLIM_INFINITY;
if (setrlimit(RLIMIT_CORE, &new_lim) != 0)
{
        printf("Core dump size set to unlimited failed.\n");

}

顺便提一下，每个进程都有一组资源限制，其中某一些可以用 getrlimit 和 setrlimit 函数查询和更改。其声明如下：
int getrlimit(int resource,struct rlimit *rlptr);
int setrlimit(int resource,const struct rlimit rlptr);

完成上面的设置之后，当 release 版本出现段错误之后，就会将信息输出到指定位置的 core dump 文件中。
如何查看并调试 core dump 文件呢？我们可以使用 gdb 调试，假设我们的可执行文件为 /home/tests/test，core dump 文件为/home/coredump/core_13308，那么我们可以使用以下命令来查看：
gdb ./home/tests/test /home/coredump/core_13308
然后用 bt 命令来查看堆栈信息，至于 GDB 其它的命令，我推荐一篇文章： http://blog.csdn.net/wei801004/article/details/4253911。

但是，一般我们发布出去的 release 版本的可执行文件都是经过优化的，比如 strip ， -O 2。而经过优化之后，会去掉可执行文件符号表中许多对调试很有用的信息，但是这些信息对于正常的运行来说没有丝毫影响，所以不必担心。我们如果要调试 release 版本生产的 core dump 文件，就必须先备份一份未经优化的可执行文件，而一般我们编译成 release 版本，都会优化，那么如何去掉 release 版本编译时优化呢？如果你是使用 make file 来编译的话，就去掉 make 时 strip 和 -O 2等优化的代码即可，这个可以上网找一下；如果你是直接在 Linux 下使用集成的开发环境如 Code blocks，那就要设置一下编译的选项。

        1. 不要勾选 Project->Bulid options 选项卡中的Strip all symbols from binary (minimizes size) [-s]选项，如下图：

这个是为了不要优化可执行文件，保留符号表中对调试有用的信息。

    2. 勾选 Project->Bulid options 选项卡中的Produce debugging symbols [-g]选项，如下图：

这是为了增加一些更详细的调试信息，比如出现段错误，会告诉你出现在哪个函数的哪一行。

        这样，我们编译出来的 release 版本就是未经优化的，这样符号表中包含了大量的对调试有用的信息，不过这样编译出来的可执行文件会比较大，不过对我们调试段错误非常有帮助。

转载请注明出处。

博主所有文章已转自私人博客 Joe 的个人博客，谢谢关注！