4. 断点管理：break设置断点、info breakpoints、delete、disable、enable、条件断点

调试这件事，说白了就是让程序在关键时刻停下来，让你看看它到底在干什么。而断点，就是我们让程序停下来的那个「哨位」。

我记得刚入行那会儿，调试全靠printf大法，满屏打印信息看得眼花缭乱。后来学会了GDB断点管理，才真正体会到什么叫「精准打击」。今天我就把断点管理的这些门道，掰开了揉碎了讲给你听。

4.1 break：设置断点的基本功

break命令，简称b，是GDB里最常用的命令。它的用法其实很灵活，我总结了几种常见场景：

(gdb) break main              # 在函数入口处下断点
(gdb) break 42                # 在源文件当前行号42处下断点
(gdb) break file.c:100        # 在指定文件的第100行下断点
(gdb) break *0x400520         # 在内存地址处下断点（汇编级）

我个人习惯在函数名上下断点，因为这样最直观。但有时候函数名会重载，比如C++里：

(gdb) break MyClass::method   # 普通成员函数
(gdb) break MyClass::method(int, char)  # 重载版本，需要带参数类型

嗯，这里要注意一点：如果函数在多个文件里都有定义，GDB会问你「你要停哪一个？」这时候可以用文件名来限定。

小技巧： 用 b 代替 break 可以少敲几个键。我写调试脚本时经常用简写，效率高不少。

4.2 info breakpoints：查看你的断点清单

断点下多了，难免会忘记自己在哪里下了断点。这时候info breakpoints（简写 i b）就派上用场了。

(gdb) info breakpoints
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x4005a0  main
2       breakpoint     keep y   0x4006b0  file.c:42
3       breakpoint     keep n   0x4007c0  func()

这张表里每一列都有用：

Num：断点编号，后面操作都要靠它
Type：断点类型，普通断点还是硬件断点
Disp：命中后的行为，keep表示保留，del表示删除
Enb：启用状态，y表示启用，n表示禁用
What：断点位置

我在项目中遇到过一种情况：调试一个多线程程序，下了十几个断点，结果程序跑起来后老是停在不该停的地方。一看info breakpoints，才发现有个断点忘了删。所以我的习惯是，每次调试前先跑一遍 i b，心里有个数。

4.3 delete、disable、enable：断点的生命周期管理

断点不是下了就不管了。有时候我们需要临时关掉某个断点，有时候要彻底删除。这三个命令就是干这个的：

命令	作用	示例
delete (d)	永久删除断点	d 1 删除1号断点，d 删除所有
disable (dis)	临时禁用断点	dis 2 禁用2号断点
enable (en)	重新启用断点	en 2 启用2号断点

你想想看，delete和disable的区别在哪？delete是彻底删除，断点编号会被回收。disable只是暂时关掉，编号还在，随时可以重新打开。

我曾经犯过一个低级错误：调试一个循环时，想临时跳过某个断点，结果用了delete。等我想恢复的时候，发现断点编号都没了，只能重新下。后来我就学乖了，临时不用的断点一律用disable。

注意： delete 不加编号会删除所有断点！我见过有人手滑敲了个 d 回车，结果所有断点全没了。建议养成习惯，每次 delete 都带上编号。

4.4 条件断点：让断点更聪明

普通断点每次经过都会停，但很多时候我们只关心特定条件下的情况。比如循环第100次时，或者某个变量等于特定值时。这时候条件断点就派上用场了。

(gdb) break 42 if i == 100
(gdb) break func if x > 0 && y < 10
(gdb) break file.c:200 if strcmp(str, "error") == 0

条件断点的语法很简单：在普通断点后面加 if 条件表达式。条件可以是任何合法的C/C++表达式。

我记得有一次调试一个内存泄漏问题，程序跑了几万次才出现一次异常。如果用普通断点，我得手动按几十次 continue，手指都按酸了。后来用了条件断点：

(gdb) break malloc if size > 1024

只监控分配超过1K内存的情况，一下子就定位到了问题。

  核心要点： 条件断点虽然好用，但要注意性能。每次经过断点时，GDB都会停下来评估条件表达式。如果条件很复杂，或者断点被频繁触发，程序会明显变慢。我一般只在关键路径上用条件断点。

4.5 断点管理实战技巧

说了这么多，我总结几个实战中常用的套路：

批量操作：可以用范围语法，比如 disable 1-5 禁用1到5号断点
临时断点：用 tbreak 下的断点，命中一次后自动删除，适合单次调试
断点忽略次数：ignore 1 100 表示忽略1号断点前100次命中
断点命令列表：commands 1 可以给1号断点绑定一组命令，命中后自动执行

举个例子，我想在每次进入函数时打印参数值，然后自动继续：

(gdb) break func
(gdb) commands
> print arg1
> print arg2
> continue
> end

这样每次命中断点，GDB会自动打印参数并继续运行，省得我手动操作。

避坑指南： 我曾经在调试一个实时系统时，在中断处理函数里下了断点。结果程序一进中断就停住，整个系统直接挂死。后来才意识到，实时系统的中断处理函数里不能随便下断点，否则会破坏时序。这种情况下，我一般用条件断点加计数，或者干脆用日志代替。

4.6 本章小结

断点管理是GDB调试的核心技能。说白了，就是三个问题：在哪里停？什么时候停？停了之后怎么办？

break 解决「在哪里停」的问题
条件断点 解决「什么时候停」的问题
commands 解决「停了之后怎么办」的问题
info/delete/disable/enable 帮你管理这些断点

把这些用熟了，调试效率至少提升一倍。下次遇到bug，别急着加printf，先想想能不能用断点精准定位。

这张图把断点管理的五个核心模块串起来了。从设置断点开始，到查看、管理、条件化，再到高级技巧，每一步都是实战中必不可少的。

可可精品资料库

📚 课程目录

4. 断点管理：break设置断点、info breakpoints、delete、disable、enable、条件断点

4.1 break：设置断点的基本功

4.2 info breakpoints：查看你的断点清单

4.3 delete、disable、enable：断点的生命周期管理

4.4 条件断点：让断点更聪明

4.5 断点管理实战技巧

4.6 本章小结