gdb调试内存错误

阅读更多

程序在运行一段时间才出错，而且是内存错误。可能是指针访问错误。这种情况下，查找错误比较困难，可以使用core文件帮助查找错误。

$ 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

需要修改参数，才能使出错时产生core文件。

没有找到core文件，我们改改ulimit的设置，让它产生。1024是随便取的，要是core文件大于1024个块，就产生不出来了。

$ ulimit -c 1024 ulimit -c unlimited

$ ulimit -a
core file size (blocks, -c) 1024
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

产生core文件，可以使用gdb调试：

可执行程序是叫做bin(通常core文件就叫做bin.core)，使用下面命令

1.gdb ./bin ./bin.core

2.使用bt命令看frames，假定在n

3.使用frame n调整frame

4.这个时候可以p任何argument或者local variable

调试p string这样的对象的值，可能由于过长，可以p string 的私有成员,如果p arg1.dat，这样可以通过p arg1.dat+100这样进行偏移。

这样获得了这些数据以后，我们可以将这些数据取出来，构造core的条件，单步跟踪，今天我就用这样的方法找到了一个bug。

主要使用到第二条，就可以发现错误出现位置。在core文件内容中，显示的 第一个出现在某个文件的 行数，就为该行出现的错误。仔细查看该行。之后的一些信息就是函数调用的 逐行退出。而且每个都有位置标志。