关于GDB调试一些笔记

当程序卡住的时候，如何通过GDB判断卡在哪里？

 

程序运行没有“反应”，或出现卡死现象，此时除了猜测代码逻辑以外，可以通过GDB进行调试

 

首先获取进程的PID，可以通过Top命令获取

也可以通过

ps -aux | grep xxx     xxx为你程序前几个字符，区分大小写，可以一个字母也可以多个，但要连续。

 

获取PID，之后

输入 gdb -p xxxx    xxxx 为前面获得的pid号，数字

含义： “GDB进入正在运行的进程”

 

此时，程序会断点在某一处

如果程序真的卡死，此时就是断点在卡死的地方，可以通过打印出来信息，然后再结合源码，猜测问题所在

 

此时，一般来说，要输入 bt   查看下主线程的 栈 的情况（栈是最后的表象，通过栈信息可以反推出现问题的地方）

 

但，大部分还不是真的卡死，只是某个线程卡死，导致表面卡死，这种是比较讨厌的。

可以先简单试验下

输入 n

 

此时，如果有信息有变化，说明不是完全卡死。

 

输入 info threads

可以查看，本进程里包含哪些线程，然后在进入某个线程（需要线程号）

 

输入 thread x     x为前面看到的线程号

 

此时，一般常规操作，输入 bt

查看栈情况

往往，出错了会导致栈出错，最常见分析方法（下面的图，是引用的，也有连接）

 

 

 

其他，也比较常用的一些手段

 

比如，可以运行几步，但连续运行又不行的情况

此时，可以输入  n   （单步运行，相对于VS里的 F10）

然后也可以输入 c  （继续运行，直到出错或下一个断点，F5）

 

不断，交替使用bt

然后分析

 

GDB本身是很强大的，但也不复杂，常用的也不多，多试几次，就记住了。

 

扩展阅读：

参数列表

命令	命令缩写	命令说明
list	l	显示多行源代码
break	b	设置断点,程序运行到断点的位置会停下来
info	i	描述程序的状态
run	r	开始运行程序
display	disp	跟踪查看某个变量,每次停下来都显示它的值
step	s	执行下一条语句,如果该语句为函数调用,则进入函数执行其中的第一条语句
next	n	执行下一条语句,如果该语句为函数调用,不会进入函数内部执行(即不会一步步地调试函数内部语句)
print	p	打印内部变量值
continue	c	继续程序的运行,直到遇到下一个断点
set var name=v		设置变量的值
start	st	开始执行程序,在main函数的第一条语句前面停下来
file		装入需要调试的程序
kill	k	终止正在调试的程序
watch		监视变量值的变化
backtrace	bt	产看函数调用信息(堆栈)
frame	f	查看栈帧
quit	q	退出GDB环境