调试Linux程序的时候，出现Segmentation Fault是最郁闷的事情了，程序代码量很大的时候，可能花很多时间都找不到出错原因。
这里介绍一种对你调试Segmentation Fault很有帮助的方法，可能能迅速帮助你找到出错的代码行。
这种方法需要用到Linux提供的core dump机制：当程序中出现内存操作错误时，会发生崩溃并产生核心文件（core文件）。使用GDB可以对产生的核心文件进行分析，找出程序是在什么时候崩溃的和在崩溃之前程序都做了些什么。
首先，你的Segmentation Fault错误必须要能重现（废话…）。
然后，依次按照下面的步骤来操作：
（1）无论你是用Makefile来编译，还是直接在命令行手工输入命令来编译，都应该加上 -g选项。
（2）一般来说，在默认情况下，在程序崩溃时，core文件是不生成的（很多Linux发行版在默认时禁止生成核心文件）。所以，你必须修改这个默认选项，在命令行执行：
ulimit -c unlimited
表示不限制生成的core文件的大小。
（3）运行你的程序，不管用什么方法，使之重现Segmentation Fault错误。
（4）这时，你会发现在你程序同一目录下，生成了一个文件名为 core.*** 的文件，即核心文件。例如，“core.15667”这样的文件。
（5）用GDB调试它。假设你的可执行程序名为test，则在命令行执行：
gdb test core.15667
然后可能会显示出一堆信息：
GNU gdb Fedora (6.8-27.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “i386-redhat-linux-gnu”…
warning: Can’t read pathname for load map: Input/output error.
…………………（中间还有很多内容，此处省略）……………………………
Loaded symbols for /usr/lib/libgpg-error.so.0
Core was generated by `./test’.
Program terminated with signal 11, Segmentation fault.
[New process 15668]
#0 0x0804c760 in thread _handler () at test.cpp:707
707 CDev* cur_dev = *it_d;
然后我们输入并执行命令 bt ：
(gdb) bt
就会得到类似于下面的信息：
#0 0x0804c760 in thread _handler () at test.cpp:707
#1 0x006b149b in start_thread () from /lib/libpthread.so.0
#2 0x0060842e in clone () from /lib/libc.so.6
于是，我们一眼就看出来了：程序是在第707行使用指针时出的问题。
怎么样，方便吧？
文章来源：http://www.codelast.com/
如果是在Arch Linux ARM上，就算你已经设置了 ulimit -c unlimited，那么仍然可能不会在程序的同一目录下生成 core.xxx 文件，这是因为生成的 core 文件能是在别的目录下，并且文件名不是 core.xxx，所以，为了能方便地调试程序，可以让core dump显得“正常”一点：
ulimit -c unlimited sysctl -w kernel.core_pattern=core
然后再试一下，就会发现在程序同一目录下生成了 core.xxx 文件。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤
转载需注明出处：codelast.com
感谢关注我的微信公众号（微信扫一扫）：
