问题背景
写过c 的朋友都知道，有时候程序编译通过，并不能代表程序就是对的。在linux下做开发时，经常会遇到跑崩溃的情况，但是在终端只会报segmentation fault，这种情况大部分原因都是诸如访问越界，指针非法操作等等问题，如果工程代码量少，你还能重新debug一下慢慢找，但是对于大型工程，想短时间内找到是很难的。
问题解决
实际上，程序运行崩溃或中止时，会在当前目录下生成一种core文件，记录了异常时的运行状态等信息，通过gdb调用这个core文件就可以快速定位到错误。这里举例说明：
假如我写了个源程序如下：
// hello.cpp #include#include int main() { while(1) { char *p = new char(); delete p; p = nullptr; *p = '2'; sleep(1); } return 0; }
指针p new完后又delete掉了，此时p已经为空，如果此时再执行*p = '2'; 就会出问题，但是编译器不知道，因为代码的类型检查都通过了。
# 编译通过 g -g hello.cpp -o hello # 当前目录下有两个文件 ls test.cpp test
我们通过./test执行程序，就会出现如下图的错误。
但是此时并不会生成core文件，需要通过命令开启core文件的生成：
ulimit -c 0 # -c后面的参数实际就是限制core文件的大小，设置为0表示不允许生成core ulimit -c 100
然后重新执行./test，报错误后就会发现当前目录下多了core文件。此时使用gdb调试就可以复现定位问题了：
gdb -c core test
在这里就可以通过调用栈等信息快速定位问题。
