gdb用法（二） 在Linux下产生并调试core文件

分析核心（core）文件

在程序发生崩溃时，有时可能无法直接运行GDB来进行调试。比如程序可能是在另外一台机器上运行的，或者因为程序对时间比较敏感，所以手动跟踪调试会产生 无法接受的延迟等。遇到这些情况，就只能等到程序运行结束后才能判断崩溃的原因了。这时需要用到Linux提供的core dump机制。当程序中出现内存操作错误时，会发生崩溃并产生核心文件。使用GDB可以对产生的核心文件进行分析，找出程序是在什么时候崩溃的和在崩溃之 前程序都做了些什么。当然，如果要用GDB来分析核心文件，也必须在编译时加上-g选项来产生调试符号表。

在分析核心文件之前必须确认系统是否允许生成核心文件，很多Linux发行版在默认时禁止生成核心文件。为了生成核心文件，首先必须执行下面的命令：
# ulimit -c unlimited
然后就可以生成核心文件了。

$ uname -a
Linux dev 2.4.21-9.30AXsmp #1 SMP Wed May 26 23:37:09 EDT 2004 i686 i686 i386 GNU/Linux

再看看默认的一些参数，注意core file size是个0，程序出错时不会产生core文件了。

$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 2048
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited

这里仍以前面的debugme程序为例，再次执行下面命令将产生核心文件：

# ./debugme
            Enter a string to count words:Happy new year!
            The number of words is 3.
            Segmentation fault (core dumped)

生成的核心文件名根据系统配置的不同会有所差异。要在GDB中分析核心文件，除了要给出核心文件的文件名外，还必须给出生成该核心文件的可执行程序的名称，示例如下：

#gdb debugme core.547
            ……
            Program terminated with signal 11, Segmentation fault.
            Reading symbols from /lib/libc.so.6...done.
            ……

从GDB的输出信息中可以看出，产生这个核心文件的原因是因为程序收到了序号为11的信号。如果想知道程序在崩溃之前运行到了哪里，可以使用“backtrace”或“info stack”命令查看一下堆栈的历史记录。示例如下：

(gdb) info stack
            #0 0x4000c6ac in _dl_fini () from /lib/ld-linux.so.2
            #1 0x40057940 in exit () from /lib/libc.so.6
            #2 0x4004291f in _libc_start_main () from /lib/libc.so.6

由上可知，程序崩溃时正处于_dl_fini()函数之中。但很多时候程序员感兴趣的可能并不是这个，而是exit()或_libc_start_main()函数，因为它们才可能是问题真正的症结所在。GDB提供的“frame”命令可以用来在不同的调用上下文中切换。例如下面的命令可以查看exit()函数在执行时的状况：

(gdb) frame 1
            #1 0x40057940 in exit () from /lib/libc.so.6

此外还可以用“up”或“down”命令在不同的函数调用上下文中切换。开发人员使用这三条命令可以很轻松地实现调用栈的遍历。在分析核心文件时，通过将遍历栈的命令和检查变量值的“print”命令结合起来，就能够复原程序运行时的全部景象。