问题调试和定位
进程异常退出时，操作系统会产生 core dump 文件，cored ump 文件是进程异常退出前内存状态的快照，运行 GDB 分析 core dump 文件可以帮助调试和定位问题。
1）首先，分析 core dump 查看导致进程异常退出的具体信号和退出原因。
使用 GDB 调试实例一（代码清单 3）的分析结果如下：
- [root@machine ~]# gdb demoSegfault core.24065
- ( 已省略不相干文本 )
- Core was generated by `./demoSegfault'.
- Program terminated with signal 11, Segmentation fault.
|
分析结果显示，终止进程运行的信号是 11，SIGSEGV，原因是内存非法访问。
2）然后，定位错误代码。
在 GDB 分析 core dump 时，输入“bt”指令打印进程退出时的代码调用链，即 backtrace，就可以定位到错误代码。
用 gcc 编译程序时加入参数 -g 可以生成符号文件，帮助调试。
重新编译、执行实例一，并且分析 core dump 文件，定位错误代码：
- [root@machine ~]# gcc -o demoSegfault demoSegfault.c -g
- [root@machine ~]# ./demoSegfault &
- [1] 28066
- [1]+ Segmentation fault (core dumped) ./demoSegfault
- [root@machine ~]# gdb demoSegfault /corefiles/core.28066
- ( 已省略不相干文本 )
- Core was generated by `./demoSegfault'.
- Program terminated with signal 11, Segmentation fault.
- #0 0x0804835a in main () at demoSegfault.c:5
- 5 str[0] = 'H';
- (gdb) bt
- #0 0x0804835a in main () at demoSegfault.c:5
- (gdb)
|
在加了参数 -g 编译后，我们可以用 gdb 解析出更多的信息帮助我们调试。在输入“bt”后，GDB 输出提示错误出现在第 5 行。
3）最后，在定位到错误代码行后，就可以很快知道根本原因，并且修改错误代码。
