gdb调试Segmentation fault经验总结

from http://blog.sina.com.cn/s/blog_7ce2cb410100rmy4.html

当程序发生Segmentation fault的时候，大多数时候可以用printf就能搞定。

但有时候可能遇到比较复杂的情况：比如，程序是已经执行完我们自己写的程序的最后一句代码了才Segmentation fault。这种情况printf就无用。就要请出大名鼎鼎的gdb了

下面是用gdb 找Segmentation fault的大致方法。适用于可执行程序和库。我的系统是Ubuntu 10

1.在终端上执行

ulimit -c 1000

2.编译程序或库，要加-g -rdynamic

3.运行程序，Segmentation fault会发生，同时也产生一个core文件

4.执行 gdb test core。就会提示出现Segmentation fault的位置，例如

#0 0x00922ff4 in xx () from /usr/lib/libtest.so

一些注意：

1. ulimit的值是对每终端有效，如果执行了一次ulimit -c VALUE以后，想重新把这个值改大一点，要重新打开一个新终端设置。

2. 如果gdb没有明确提示Segmentation fault的位置，比如，它这样show

#0 0x00922ff4 in ?? () from /usr/lib/libtest.so

这真叫人沮丧的，前面忙活了半天，最想看的却看不到。

咋办？

1). 执行一下bt命令，也许回有意外收获

2). 检查编译的时候是不是加了-g -rdynamic

3. 有些Segmentation fault来得太猛烈了，core文件还没产生完整程序就退出了。这时候即使用gdb test core也看不到出错点。咋办？

我的经验是多执行几次你的程序，一定要让core文件完整产生。每产生一次，就用gdb test core去试，总有成功的时候。