问题背景
写过C++的朋友都知道,有时候程序编译通过,并不能代表程序就是对的。在linux下做开发时,经常会遇到跑崩溃的情况,但是在终端只会报Segmentation fault,这种情况大部分原因都是诸如访问越界,指针非法操作等等问题,如果工程代码量少,你还能重新debug一下慢慢找,但是对于大型工程,想短时间内找到是很难的。
问题解决
实际上,程序运行崩溃或中止时,会在当前目录下生成一种core文件,记录了异常时的运行状态等信息,通过gdb调用这个core文件就可以快速定位到错误。这里举例说明:
假如我写了个源程序如下:
// hello.cpp #include <iostream> #include <unistd.h> 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
在这里就可以通过调用栈等信息快速定位问题。