断点、观察点、捕获点：调试会话的生命周期管理

调试这件事，说白了就是让程序在特定时刻停下来，让你看看它到底在干什么。GDB 里最核心的三个武器——断点、观察点、捕获点，各有各的脾气。我这些年重构过不少大型项目，每次遇到诡异的 bug，最后都是靠它们组合使用才揪出来的。

断点：最基础的暂停键

断点大家都会用，但你真的用对了吗？

我见过太多人只会 b main 或者 b 行号。其实断点有很多种玩法：

• 普通断点：break function_name 或 break filename:line_number
• 条件断点：break foo if x > 5 —— 只有满足条件才停
• 临时断点：tbreak main —— 只停一次，自动删除
• 硬件断点：hbreak —— 用于只读内存区域

(gdb) break process_order if order_id == 1024
(gdb) break file.c:256 if strcmp(name, "critical") == 0

嗯，这里要注意：条件断点会拖慢执行速度。因为每次经过断点位置，GDB 都要停下来评估条件。我曾经在一个高频交易系统里用过条件断点，结果程序直接超时了……后来改用硬件断点才解决。

观察点：盯着变量不放

断点是按位置停，观察点是按数据停。说白了就是：你告诉 GDB 盯着某个变量，只要它变了，就立刻停下来。

观察点有三种：

类型	命令	触发条件
写观察点	watch var	变量被写入时
读观察点	rwatch var	变量被读取时
读写观察点	awatch var	变量被读或写时

我遇到过最经典的场景：一个全局变量莫名其妙被改成了 0，但代码里明明没有赋值语句。用 watch global_var 一盯，发现是某个回调函数里通过指针越界写到了它。这种 bug 用断点根本查不出来。

捕获点：捕捉系统事件

捕获点比较冷门，但用好了很强大。它不盯代码也不盯变量，而是盯事件——比如 C++ 异常、系统调用、信号等。

(gdb) catch throw          // 捕捉 C++ 异常抛出
(gdb) catch syscall write  // 捕捉 write 系统调用
(gdb) catch signal SIGSEGV // 捕捉段错误信号

我曾经在重构一个网络库时，发现程序偶尔会崩溃。用断点根本复现不了，因为崩溃是随机的。后来用 catch syscall mmap 一抓，发现是某次内存映射返回了失败，但代码没检查返回值。嗯，这种问题只有捕获点能搞定。

调试会话的生命周期管理

一个调试会话，从启动到结束，其实是有生命周期的。我把它分成四个阶段：

1. 启动阶段：加载程序、设置参数、配置环境
2. 配置阶段：设置断点、观察点、捕获点
3. 运行阶段：执行、暂停、检查、修改、继续
4. 清理阶段：删除断点、保存状态、退出

这里有个实用技巧：用 save breakpoints 保存断点配置，下次调试直接 source 加载。我在重构一个百万行项目时，经常需要反复调试同一个模块，每次都重新设断点太烦了。

(gdb) save breakpoints my_breakpoints.txt
(gdb) source my_breakpoints.txt

调试会话结束时，记得用 delete 清理断点。不然下次调试时，旧断点还在，容易混淆。我刚开始用 GDB 时就吃过这个亏——调试了半天，发现断点根本没生效，原来是被之前的断点干扰了。

三种点的配合使用

说实话，单独用某一种点，效果有限。真正的高手是组合使用：

• 先用断点定位到可疑函数
• 再用观察点盯住关键变量
• 最后用捕获点捕捉异常事件

举个例子：我在调试一个内存泄漏时，先用断点停在分配函数，然后用 watch 盯住指针变量，最后用 catch syscall brk 监控堆内存变化。三个点一配合，问题原形毕露。

SVG 知识体系图

这张图把三种调试点和生命周期串起来了。你仔细看，断点、观察点、捕获点分别对应了不同的调试维度，而生命周期管理则贯穿始终。说白了，调试不是乱停乱看，而是有策略、有节奏的。

最后说一句：别怕用错，多试几次就熟了。我刚开始用观察点时，设了 10 个，结果程序慢得像蜗牛。后来才知道硬件资源有限。这些坑，踩过一次就记住了。

可可精品资料库