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去试，总有成功的时候。