用gdb调试core dump文件

尊重原创：http://blog.chinaunix.net/u2/83905/showart_2134570.html

 

 

在Unix系统下，应用程序崩溃，一般会产生core文件，如何根据core文件查找问题的所在，并做相应的分析和调试，是非常重要的。

什么是Core Dump?
Core的意思是内存, Dump的意思是扔出来, 堆出来.开发和使用Unix程序时, 有时程序莫名其妙的down了, 却没有任何的提示(有时候会提示core dumped). 这时候可以查看一下有没有形如core.进程号的文件生成, 这个文件便是操作系统把程序down掉时的内存内容扔出来生成的, 它可以做为调试程序的参考.
core dump又叫核心转储, 当程序运行过程中发生异常, 程序异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 叫core dump.

为什么没有core文件生成呢?
有时候程序down了, 但是core文件却没有生成. core文件的生成跟你当前系统的环境设置有关系, 可以用下面的语句设置一下, 然后再运行程序便成生成core文件.
ulimit -c unlimited
core文件生成的位置一般于运行程序的路径相同, 文件名一般为core.进程号

当获得了core文件以后，就可以利用命令gdb进行查找，参数一是应用程序的名称，参数二是core文件
如： gdb [...]xmsd [...]/xmsd_PID1065_SIG11.core

然后输入bt或者where找到错误发生的位置和相应的堆栈信息。就可知道发生错误时的函数调用关系，然后可以使用up或者down查看上一条和下一条具体详细信息。这样便能对问题进行大概定位，然后看源代码，进行分析。

eg：

(gdb) where #0 0x0804ff8c in memory_error (self=0x818ca10, ptr=0x82e5a94, msg=0x813efb2 "memory_free") at /aston/h_debit/XMS/bin/XMS_1_15_11/src/xms/lib/memory.c:140 #1 0x080504cd in memory_free (ptr=0x82e5a94) at /aston/h_debit/XMS/bin/XMS_1_15_11/src/xms/lib/memory.c:275 #2 0x080505ac in xml_free (ptr=0x82e5a94) at /aston/h_debit/XMS/bin/XMS_1_15_11/src/xms/lib/memory.c:316 #3 0xb7edb589 in xmlFreeNode () from /home/zhenbo/workstation/DEVSUITE-HEAD/debug/lib/libxml2.so #4 0x082b2228 in ?? () #5 0x08097031 in interfacehandler_set (self=0x82bd74c, correlator=-4, conf=0x0, cb=0x82b0aac) at /aston/h_debit/XMS/bin/XMS_1_15_11/src/interfaces/interfacehandler.c:150 #6 0x0805e897 in configurable_set (self=0x82bd74c, correlator=-4, conf=0x0, cb=0x82b0aac) at /aston/h_debit/XMS/bin/XMS_1_15_11/src/xms/xms/configurable.c:85 #7 0x0805e73c in configurable_flush (self=0x82bd74c, correlator=-4, cb=0x82b0aac) at /aston/h_debit/XMS/bin/XMS_1_15_11/src/xms/xms/configurable.c:67 #8 0x08100ddc in system_complete (self=0x82b0aac, correlator=-5, code=0

如果之前不能准确定位错误的位置，则从以上信息可以知道，可从函数interfacehandler_set入手进行分析，其中的参数和行号都已经给出了。

 

 

 

 

 

 

 

1. 前言:
有的程序可以通过编译, 但在运行时会出现Segment fault(段错误). 这通常都是指针错误引起的.
但这不像编译错误一样会提示到文件->行, 而是没有任何信息, 使得我们的调试变得困难起来.

2. gdb:
有一种办法是, 我们用gdb的step, 一步一步寻找.
这放在短小的代码中是可行的, 但要让你step一个上万行的代码, 我想你会从此厌恶程序员这个名字, 而把他叫做调试员.
我们还有更好的办法, 这就是core file.

3. ulimit:
如果想让系统在信号中断造成的错误时产生core文件, 我们需要在shell中按如下设置:
#设置core大小为无限
ulimit -c unlimited
#设置文件大小为无限
ulimit unlimited

这些需要有root权限, 在ubuntu下每次重新打开中断都需要重新输入上面的第一条命令, 来设置core大小为无限.

4. 用gdb查看core文件:
下面我们可以在发生运行时信号引起的错误时发生core dump了.
发生core dump之后, 用gdb进行查看core文件的内容, 以定位文件中引发core dump的行.
gdb [exec file] [core file]
如:
gdb ./test test.core
在进入gdb后, 用bt命令查看backtrace以检查发生程序运行到哪里, 来定位core dump的文件->行.