python gdb coredump_GDB 调试 C++ 程序 core dump

前天晚上(2013.10.15)参加 Topcoder 竞赛时, 碰到一个比较没有头绪的问题, 想解法就想了半天, 写代码时又出了问题,以前在 Visual Studio 下图形化调试的习惯根深蒂固,GDB 又不熟悉, 所以只能用最笨的 printf 来进行调试, 大大降低了效率, 到了急需砍柴时才后悔没有磨好刀啊.

现在趁着有时间, 就把 GDB 再好好练习一下, 就不罗列一大堆命令了, 只是把碰到的/用过的整理一下, 以后再使用到新的命令, 再补充. 有几篇总结的比较好的文章可以参考: 《LINUX C/C++ GDB调试(概述)上》、《LINUX C/C++ GDB调试(概述)下》、《手把手教你玩转GDB(二)——Breakpoint, Watchpoint和Catchpoint》

1.添加调试信息为了能使用 gdb 进行调试, 需要添加 -g 选项添加调试信息.

g++ -g test.cpp -o test

2.常用命令

使用 gdb test 即可以进入调试程序, 以下列出几个常用命

令.

显示图形化代码 Ctrl+x+a

启动程序 r (run)

断点 b (breakpoint)

清除/禁用/启用断点 delete/disable/enable

单步 s (step 碰到函数会进入)

单行 n (next 碰到函数不会进行, 而是整条执行)

执行到下一个断点 c (continue)

查看变量 p (print)

显示变量 display

查看当前调用堆栈 bt (backtrace)

查看某一层调用代码 f (frame)

3.调试 core dump程序执行时, 经常会因为段错误(Segment Fault)而退出, 操作系统会把此程序当前内存信息 dump 到磁盘上(详见wiki), 即生成 core 文件. 对 core 进行分析可以很快分析出导致程序 crash 的地方.

(1).设置 core 文件大小

系统默认不会生成 core 文件, 需要进一步设置. core 文件的生成依赖于 shell 的设置, 在 shell 中运行命令: ulimit -a, 从第一行的设置项可以看到系统设置的 core file size 为 0, 即不生成 core file.

使用命令: ulimit -c unlimited 可以设置 core file size 为无限.

(2).生成简单 core 文件在 C++ 中制造一个 segment falt 太容易了, 直接给一个空指针赋值就可以了.

int main(int argc, char const *argv[])

{

char* p = nullptr;

*p = 'a';

return 0;

}

保存文件为 coreDumpTest.cpp, 编译并运行, 即可以现磁盘上多了一个 core 文件, 就是这个程序发生段错误 dump 下来的进程信息.

(3).调试简单 core 文件使用gdb ./coreDumpTest core来调试 core, 发现 gdb 直接就定位到了出错的语句(第4行赋值语句), 还可以通过 print 来查看当前上下文变量, 如指针 p 的值为 nullptr.

(4).生成稍复杂 core 文件

上面的例子太简单了, 下面通过一个稍微复杂的例子来介绍一下 gdb 中命令 backtrace 和 frame 的使用. 下面代码很简单, 就是越界访问, 用 vector 是为了体现调用层次...

#include

using namespace std;

int main(int argc, char const *argv[])

{

vector a;

vector b;

b.push_back(a[0]);

return 0;

}

(5).调试稍复杂 core 文件

编译运行程序, 生成 core 文件,使用

gdb

来调试 core, 可以看到此时直接定位到的地方是库函数中的某一行;

库函数都是经过千锤百炼, 基本不可能出错, 所以我们先从自己的程序找起. 这时我们需要知道的是代码是从哪条语句执行到这里的, 使用

backtrace(或者 where)

命令列出当前调用堆栈, 再使用

frame n

命令列出第 n 层堆栈的信息, 就可以直接看到出错的代码语句了, 接下来就是进一步分析了.

4.环境:Ubuntu 12.04(64-bit) + gcc 4.8.1 + gdb 7.6.1

待添加: 设置 core file size 在所有 shell 都生效, 不要每次打开一个 shell 就要设置一下.