前言
谈论gdb重要性
一般来说。提gdb,命令用于调试。“命令”,用户是几乎相同的复杂话。而事实确实如此,实际的开发调试必须用到gdb。
如今。大多数Linux系统是存在于server其中。
我们想操作这些系统时,通常是通过Terminal来操作。也就是说这些Linux系统不具有图形界面。而调试一般分两部分。开发时调试和执行时调试。
当我们的程序部署到Linux上时。那就须要忘记那该死图形调试器了。
说说写这篇文章的目的
昨天公司游戏的当中服务端崩溃了。我在调试时忘记了gdb命令-_-!(当然最后我是找出这个Bug了)。因此写这篇博文加深记忆。同一时候分享一下经验。
基础命令
注:gdb远不止这么少的命令
1. attach: 用gdb调试一个正在执行中的进程
gdb <program> PID 或 gdb attach PID
2. br: 设置断点
br filename:line_num
br namespace::classname::func_name
3. n: 单步跳过 s: 单步进入
4. finish:运行到函数retun返回
5. list: 列出当前位置之后的10行代码。list line_number: 列出line_number之后的十行代码
6. bt(backtrace):列出调用栈(同类型的还有where,经验告诉我。当你想列出堆栈信息时,而发现没有效果,最好两个命令都试试)
7. info locals:列出当前函数的局部变量
8. p var_:打印变量值
9. info breakpoints:列出全部断点
10. delete breakpoints:删除全部断点;delete breakpoints id:删除编号为id的断点。disable/enable breakpoints id:禁用/启用断点
11. break ... if ... 条件中断
以下我主要讲述的是执行时调试。
測试代码
#include <stdio.h>
void Crash()
{
int *a;
*a = 1;
printf("%d\n", *a);
}
void EndlessLoop()
{
int i = 1;
int j = 0;
while (i)
{
++j;
}
}
int main()
{
Crash(); // 崩溃
EndlessLoop(); // 死循环
return 0;
}
调试崩溃
http://blog.csdn.net/yitouhan/article/details/17175113 这是我之前写的一篇关于防止崩溃的文章。
这里用到core文件:
在一个程序崩溃时,它通常会在指定文件夹下生成一个core文件。
core文件不过一个内存映象(同一时候加上调试信息),主要是用来调试的。
这个core的文件名称通常是core.PID,即core.3745等等
我通常会在/etc/security/limits.conf(Centos)设置Linux对core的支持。这须要重新启动系统,之后就会永久支持打印core文件。
加入以下命令
* soft core unlimited
* hard core unlimited
意思是软件和硬件都打印core文件,并且是unlimited(无限制)。
这里能够将unlimited替换成指定的大小。
注:还有其他的一些设置方式,能够自行上网搜索查询。
就在此时。服务端test崩溃了。
在我的工作文件夹中发现了core.1234这个文件(core文件默认输出到工作文件夹)。
输入gdb test core.1234进入gdb调试。
这时再输入where查看堆栈信息,例如以下图:
看到这些信息,不要告诉我还找不到出错的地方吧?!
调试死循环
当我们发现死循环的时候不要中止进程。如果进程ID是1234
输入命令 gdb attach 1234
你会发现gdb会断点在死循环的地方,或许可能不是非常清楚,你能够一直输入n。
注意行号。你会发现这就是出现死循环的地方。
再输入where,来查看堆栈信息,例如以下图所看到的。
看到这些信息,不要告诉我还找不到出错的地方吧?。
半死循环
半死循环(这是我自己用的一个名词,不知道其他教程等是否有使用)就是在执行的时候出错,导致循环了几百万次、几千万次甚至几亿次的一种Bug。
尽管这样的Bug相对于崩溃的相对小的数目和死循环的危险,但非常难以调试。假设你有一个这样的Bug还有更好的调试经验,我希望你可以分享!