GDB高级技巧：条件断点、观察点、回溯调用栈
调试这事儿，说白了就是跟代码里的bug斗智斗勇。GDB的基本操作大家都会，但真正能让你效率翻倍的，往往是那些高级技巧。今天我就把压箱底的三板斧掏出来——条件断点、观察点、回溯调用栈。这三个东西用好了，很多让你挠头的问题，几分钟就能定位。
一、条件断点：别让程序停在不该停的地方
普通断点有个毛病：只要执行到那一行就停。但很多时候，我们只关心特定条件下的情况。比如循环1000次，只有第999次才出问题，你总不能按999次continue吧？
条件断点就是干这个的。它只在条件满足时才触发。
(gdb) break main.c:42 if count > 998
(gdb) break func if x == 5 && y != 0
(gdb) break 88 if strcmp(str, "error") == 0我个人习惯在调试复杂状态机时大量使用条件断点。比如一个网络协议栈的状态切换，我只关心进入STATE_TIMEOUT的情况，那就直接加条件断点，省得一次次手动跳过无关状态。
二、观察点：变量变了？立刻抓住它
有时候你根本不知道变量是在哪里被改写的。比如一个全局变量莫名其妙变成了0，你翻遍所有赋值语句都找不到凶手。这时候，观察点就派上用场了。
观察点（watchpoint）监控某个变量或内存地址，一旦值发生变化，GDB就会停下来，告诉你是在哪一行改的。
(gdb) watch my_var // 监控变量
(gdb) watch *(int*)0x7fff // 监控内存地址
(gdb) rwatch my_var // 只监控读操作
(gdb) awatch my_var // 监控读写操作我曾经在一个多线程项目里遇到过一个极其隐蔽的bug：一个结构体指针被某个线程意外置空了。我翻代码翻了两个小时没找到。后来用watch pStruct，程序一跑就停在了那个不该出现的赋值语句上——原来是一个同事在另一个文件里写了memset，把指针区域给清零了。
thread apply all watch。
三、回溯调用栈：从崩溃现场倒推真相
程序崩溃了，GDB停在某个函数里。你看到的是一个局部变量，但根本不知道是谁调了它。这时候就需要回溯调用栈——看看程序是怎么走到这一步的。
(gdb) backtrace
(gdb) bt
(gdb) bt full // 显示所有局部变量
(gdb) bt 10 // 只显示最近10层回溯调用栈最常用的场景是分析段错误。程序在strcpy里崩了，你光看strcpy的代码没用，得看是谁传了非法指针进来。用bt一看，哦，是process_data调了parse_string，parse_string又调了strcpy，而process_data里的input指针是NULL——问题就出在调用者身上。
你还可以在回溯栈里跳来跳去：
(gdb) frame 2 // 跳到第2层栈帧
(gdb) info locals // 看那层的局部变量
(gdb) up // 往上一层
(gdb) down // 往下一层嗯，这里要注意：优化后的代码可能会让调用栈变得不完整。有些函数被内联了，有些变量被优化掉了。所以调试时最好用-O0 -g编译，否则回溯出来的信息可能不准。
四、三板斧组合使用
这三个技巧单独用已经很厉害了，但组合起来才是真正的杀手锏。我举个例子：
假设你怀疑某个全局变量g_counter在某个条件下被错误地减了1。你可以这样操作：
- 先设一个条件断点，只在
g_counter > 100时触发 - 在断点处设置观察点
watch g_counter - 继续运行，观察点触发时用
bt看调用栈
这样你就能精确地抓到：在什么条件下、由谁、在哪个文件哪一行、把g_counter改成了什么值。整个过程可能只需要几分钟。
五、一张图理清关系
下面这张图展示了这三个技巧在调试流程中的位置和关系：
六、避坑指南
这些技巧虽然好用，但也有一些坑。我踩过的，你们就别踩了。
- 条件断点别写太复杂。我曾经写了一个带多层函数调用的条件表达式，结果GDB每次停下来都要执行一遍那个函数，程序直接慢成蜗牛。后来改成先设普通断点，再手动加条件。
- 观察点别监控局部变量。局部变量在函数返回后就失效了，观察点会自动删除。如果你非要监控，可以考虑把它改成静态变量或者全局变量。
- 回溯调用栈别信优化后的代码。用
-O2编译的程序，回溯出来的栈帧可能缺层，变量值也可能不对。调试阶段老老实实用-O0 -g。 - 多线程下要指定线程。用
thread apply 2 watch var来指定只在某个线程里监控，否则其他线程的修改也会触发，干扰判断。
好了，这三个技巧就讲到这里。下次你在GDB里调试到怀疑人生的时候，试试它们，说不定会有惊喜。
一句话总结：条件断点让你知道「什么时候停」，观察点让你知道「谁改了它」，回溯调用栈让你知道「怎么走到这的」。三个一起用，bug无处遁形。
公众号:蓝海资料掘金营，微信deep3321