写代码这么久，如果让我选一个最能提升效率的习惯，调试器的使用绝对排在前三。很多朋友一把printf走天下，觉得 gdb 是“大神专属”工具，其实学会它不过就是两小时的事。gdb 全称 GNU Debugger，是 Linux 生态里最经典的调试工具，配合 cgdb 这个终端可视化前端，连源代码窗口都省了，直接治好了我“盲人摸象”式调试的毛病。这篇文章就把我从第一条断点到 multi-thread 排障的完整经验整理出来，适合刚接触 Linux 开发的初学者，也适合那些习惯printf、想换一种更高效排障方式的同学参考。

1. 为什么非要用调试器：printf 之外的另一层世界

你可能会问，我到处加printf不也能把问题找出来吗？话是没错，但printf调试有几个很要命的短板：第一，你得改源码重新编译，一轮下来 30 秒起步；第二，程序崩了或者死循环了，printf输出未必刷得出来，就算刷出来也未必是问题现场；第三，多线程程序里，你根本不知道打印出来的时点对应的是哪一帧状态。

调试器解决问题的方式完全不同。它可以“暂停世界”，让你看清每一行代码执行时变量到底长什么样、程序栈上挂着哪些函数调用、某个值是被谁改掉的。这其实不是在“捉虫”，而是在还原犯罪现场。

1.1 调试的基本思路：单步还是断点

调试策略通常分两派：单步跟踪和断点停靠。单步适合理解代码逻辑，按next一行行走，但遇到大循环几千次迭代会按到怀疑人生。断点则是让程序跑起来，只在可疑位置暂停，效率高得多。我的习惯是：先断点，后单步，再 watchpoint。逻辑不清晰时跑一遍单步理解全貌，确认可疑函数后下条件断点，需要盯变量变化时再上 watchpoint。三者组合，没有解决不了的逻辑问题。

1.2 符号表是什么：-g选项的秘密

gdb能认出行号和变量名，靠的是编译期生成的调试符号。GCC 编译时加-g选项，会生成 DWARF 格式的调试信息，里面有源码路径、行号映射、参数和局部变量的名字与类型。没加-g编译的程序也能调试，但只能看到汇编指令，这在排查 C++ 模板展开或编译器优化导致的问题时简直灾难。

还有一点，调试编译时尽量加-O0。-O2优化会把变量优化掉、把函数内联掉，你在 gdb 里 print 某个变量，结果提示optimized out，这就是优化器把变量直接融合进寄存器或常量了。友好建议：Debug 构建一律-g -O0，Release 构建才上优化。

2. gdb 基础操作：从编译到第一条断点

先把工具装好。Ubuntu/Debian 系执行sudo apt install gdb，CentOS/RHEL 系执行sudo yum install gdb，macOS 用户执行brew install gdb后还要额外配置代码签名，过程稍麻烦。Windows 上如果你用的是 WSL，直接和 Linux 一样安装即可。

2.1 准备一个可调试的示例程序

我不讲花哨的，就用一个“链表反转”的经典例程来演示。先建一个reverse.c：

#include <stdio.h> #include <stdlib.h> typedef struct Node { int value; struct Node *next; } Node; Node* create_list(int n) { Node *head = NULL; Node *prev = NULL; for (int i = 0; i < n; i++) { Node *node = (Node*)malloc(sizeof(Node)); node->value = i; node->next = NULL; if (prev) { prev->next = node; } else { head = node; } prev = node; } return head; } void reverse_list(Node **head) { Node *prev = NULL; Node *curr = *head; Node *next = NULL; while (curr != NULL) { next = curr->next; curr->next = prev; prev = curr; curr = next; } *head = prev; } void print_list(Node *head) { Node *curr = head; while (curr != NULL) { printf("%d ", curr->value); curr = curr->next; } printf("\n"); } int main() { Node *head = create_list(5); print_list(head); reverse_list(&head); print_list(head); return 0; }

编译时务必带上调试选项：

gcc -g -O0 -o reverse reverse.c

启动 gdb 有几种方式。通常我会先运行再查看崩溃状态，也可以用gdb reverse直接开始，或者在程序出问题后用gdb reverse core分析 core 文件。第三种方式如果碰到段错误，可以直接分析程序坠毁前留下的“遗体”——core dump。

2.2 下断点：常用姿势与执行流的控制

进入 gdb 后，先看一眼源码再规划断点：

(gdb) list

如果要带上下文，可以list reverse.c:12, 25，直接定位某个函数或某一行。下断点的命令是break或者简写b：

(gdb) break reverse_list (gdb) break 22 (gdb) break reverse.c:18

第一条以函数名断下，第二条直接断在文件行号 22，第三条指定文件与行号，适合多文件工程。运行程序用run或r，程序会在第一个断点处停下。这时用info breakpoints能看到所有断点列表，disable 1临时禁用不用的断点，delete 1删掉它。

单步命令两组要分清：next和step。next执行当前行，如果当前行是函数调用，会整个调完再停到下一行，相当于“跨过”。step则会跳进函数内部，在函数第一行停住。配合finish执行完当前函数返回调用处，再配合until 30直接往后跑到第 30 行——我常用until跳出大循环，而不用傻傻按几十次next。

下面是一个模拟的调试会话核心部分：

(gdb) break reverse_list Breakpoint 1 at 0x401156: file reverse.c, line 18. (gdb) run Breakpoint 1, reverse_list (head=0x7ffc2e9d5f18) at reverse.c:18 18 Node *prev = NULL; (gdb) next 19 Node *curr = *head; (gdb) print curr $1 = (Node *) 0x55c3f2d012a0 (gdb) print curr->value $2 = 0 (gdb) next 21 while (curr != NULL) { (gdb) print *curr $3 = {value = 0, next = 0x55c3f2d012c0}

注意，print *curr能一次性看整个结构体的内容，这个操作比一个个字段打印省事太多。显示时给指针变量前面加*，gdb 会解析出实际结构体内容，非常直观。

2.3 查看调用栈：程序“从哪里来，到哪里去”

当程序停在某个断点，你很可能想知道“谁调用了我”。backtrace（或者bt）显示从main到当前断点的所有栈帧：

(gdb) bt #0 reverse_list (head=0x7ffc2e9d5f18) at reverse.c:18 #1 0x00000000004011c4 in main () at reverse.c:35

frame 1切换到 main 的栈帧，print head就能看 main 里head变量的值——因为head是局部变量，不在当前栈帧里，默认看不到，切帧后没问题了。调试多模块程序时，看调用关系是否有悖预期，比如是不是调错了重载函数，或者回调函数入口参数被写坏，bt基本是第一步。

2.4 程序崩溃瞬间：看到死因的第一现场

调试最刺激的其实是段错误。先让程序跑着，等它崩溃：

(gdb) run Program received signal SIGSEGV, Segmentation fault. 0x000000000040118a in main () at reverse.c:36 36 print_list(head);

这时别慌，先执行bt看栈，再用frame 0切进崩溃帧看看局部变量值。假如是空指针调用成员函数，gdb 直接报错，但报错的根源往往在前面几帧里。这个“顺着栈帧回溯”的习惯，帮我解决了大概 80% 的空指针问题。

3. gdb 进阶：条件断点、watchpoint 与自动化脚本

基础操作熟练后，真正拉开差距的是进阶玩法。对付特定数据才出现的 bug，条件断点比满世界设断点精准得多。

3.1 条件断点：等一个变量变成特定值

比如想在第 21 行盯着curr->value == 3的情况，直接写：

(gdb) break 21 if curr->value == 3 (gdb) run Breakpoint 1, reverse_list (head=0x7ffc2e9d5f18) at reverse.c:21 21 while (curr != NULL) { (gdb) print curr->value $1 = 3

条件断点的内部实现是：每次执行到 21 行，gdb 都会把表达式的值给求出来，不满足条件就继续。表达式里可以调用函数，也可以访问全局变量和宏。但有两点注意：条件表达式本身写错了程序不会立即发现，只会打断点失败；条件太复杂会让程序慢 10 倍以上，尤其在大循环里。这种情况我会改用 watchpoint。

3.2 watchpoint：盯着一个变量，改了立刻停

watchpoint 就是“数据的断点”。它不关心代码执行到哪一行，只关心某个变量是否被修改。硬件支持的情况下，gdb 用 CPU 调试寄存器实现无侵入监控；不支持时用软件模拟，性能会差很多。设一个：

(gdb) watch curr->next

当curr->next被篡改时，程序会立刻停在修改它的那行，还会标出旧值和新值。这是排查“谁动了我的指针”的神器，多线程下配合硬件 watchpoint 尤其管用。

我曾被一个诡异问题折磨两天：某结构体里一个字段隔一段时间就变成 0xffffffff，查来查去定位不到写入点。用 watchpoint 挂上去，跑了十分钟程序就停在了一个彻底想不到的 write 系统调用附近的赋值语句。于是才知道是缓冲区溢出踩坏了结构体。那一刻我对 watchpoint 的信任直接拉满。

3.3 gdb 命令脚本：把重复操作打包

每次调试都敲十几遍同一串命令，实在太烦。gdb 支持把命令集放进脚本用-x加载。比如写一个debug.cmd：

set pagination off set print pretty on break reverse_list if curr->value == 3 commands 1 silent printf "Hit at value=%d\n", curr->value bt 2 continue end run

然后gdb -x debug.cmd reverse启动。所有的断点动作自动执行。排查“每次崩溃前 log 一下调用来源”这类场景，脚本流能大幅提升效率。

set print pretty on输出结构体会自动换行缩进，多个嵌套结构时这体验完全离不开。set print elements 0让大数组全部显示出来，不会被默认截断成...。调试大数组或链表时这两个设置组合直接爽到飞起。

4. 多线程与 Core Dump：还原现场的最后防线

单线程调试只是基本功，多线程排障才是硬仗。多线程里最烦的一个场景——不是程序不崩溃，而是崩溃得像随机抽奖，换个环境又不崩了。这种时候，core dump 文件是唯一能还原现场的线索。

4.1 多线程调试：让世界停在下注的那一秒

gdb 里多线程调试有三板斧：查看线程列表、切换线程、锁住调度。

• info threads列出所有线程
• thread 3切换到编号 3 的线程
• thread apply all bt一次性看所有线程的调用栈，查死锁最常用
• set scheduler-locking on让单步命令只作用于当前线程
• set scheduler-locking off允许其他线程继续跑（默认行为）

有次我调一个资源竞争问题，两线程同时操作一个全局链表。我分别在两个线程里下条件断点，然后thread apply all bt一看——两个线程的栈帧都停在同一断点附近，其中一个正在修改链表，另一个同时也在修改，谁都没拿锁。数据竞争立刻现形，不需要再靠猜。

死锁的定位方法也很直接：看到多个线程都阻塞在pthread_mutex_lock之类的调用上，基本锁粒度或者锁顺序出了问题。

这里有个极易踩的坑：在有锁的循环里使用next单步，如果调度锁没开，另一个线程可能会推进共享状态，导致你 debug 出来的执行流和真实情况差别很大。排查多线程问题第一步永远是set scheduler-locking on。

4.2 配置 core dump：崩溃之后还有救

core dump 默认经常关闭。先检查：

ulimit -c

输出 0 表示关闭，用ulimit -c unlimited放开。想让配置持久化，写进~/.bashrc或/etc/security/limits.conf。临时路径下生成的 core 文件通常在程序工作目录里，名字形如core或core.12345，具体看/proc/sys/kernel/core_pattern配置。

gdb reverse core

进去之后bt看崩溃栈，frame切到崩溃帧看变量，再用list看崩溃位置的上下文源码。这个流程不需要复现 bug，不需要跑几千次，只要拿到现场，问题就基本锁定了。个人强烈建议：每次接手别人项目之前，先确认 core dump 功能是开着的。不然遇到那种“用户机器必现，开发环境死活不崩”的 bug，你可就极被动了。

core dump 还有一个延伸技巧：coredumpctl。systemd 系统的发行版可以用coredumpctl gdb reverse自动调起 gdb 分析最近的 core，省去找文件的功夫。

5. cgdb：给 gdb 装上一双可以看到代码的眼睛

gdb 本身是纯命令行交互，默认只能通过list命令一页页翻源码，断点看不了源码上下文。时间久了眼睛确实累。cgdb 就是在 gdb 外面套一个终端文本界面，上屏显示源码，下屏保留 gdb 命令行，这个设计简单直接，但体验提升是质变的。

5.1 安装 cgdb：一条命令

Debian/Ubuntu：

sudo apt install cgdb

CentOS/RHEL 需要先启用 EPEL：

sudo yum install epel-release sudo yum install cgdb

macOS：

brew install cgdb

安装好以后没什么额外配置，cgdb build/bin/你的程序直接启动。如果显示界面花屏或者配色奇怪，基本是终端类型没设置好，export TERM=xterm-256color能解决绝大多数问题。

5.2 上下分屏：源码与命令行的无缝切换

cgdb 启动后默认进入一个上下分割的界面：上方是源码窗口，下方是 gdb 命令窗口。焦点所在窗口高亮显示。在下方窗口输入 gdb 命令，上方的源码窗口会实时更新当前执行位置和断点。

分屏交互有几个快捷键必须记住：

• Esc从命令窗口切到源码窗口
• i从源码窗口切回命令窗口
• 源码窗口下按空格在当前行设置或取消断点
• F5发送run，F8发送next，F7发送step
• F9发送continue
• -和=缩放源码窗口

用几天后你基本就离不开空格下断点 + F5 启动 + F8 单步这套组合了，全程不碰键盘敲命令。

5.3 cgdb 调试实录：体验一次完整流程

实际的流程你感受下：

cgdb reverse

启动后在命令窗口输入break reverse_list回车，上方源码窗口第 18 行高亮变成红色，代表有断点。按F5，程序跑起来停在断点处。按一次F8，代码高亮行移动到第 21 行。这时候使用i切到下窗口，输入print curr->value，数值立刻显示。处理完后再按Esc切回上窗口继续按F8。

cgdb 真正让我心动的是看循环变量迭代过程：单步时高亮行在while和循环体之间来回移动，眼前看的是源码，右手按的是 F8，脑子想的是逻辑——零切换成本。原来在纯 gdb 里你要背下来“现在执行到第几行”，现在直接看高亮，这份“眼睛不累”的舒适感是最大的隐性收益。

5.4 配置优化：几个让 cgdb 更好用的设置

默认设置的 cgdb 信息展示还不够丰富，可以在~/.cgdb/cgdbrc里写上：

set cgdb/arrows=1 set cgdb/showgdb=1 set cgdb/helpline=1 set cgdb/splitwin=vertical

这些配置开启方向键滚动、显示 gdb 子窗口、开启底部帮助，以及把分屏从上下改成左右。左右分屏在宽屏终端下特别好用，左边源码、右边命令，各行其道。字体大小不用管，继承终端设置。若用 iTerm2 或 Konsole，把字号调大一点，体验更舒服。

6. 问题速查与经验总结

最后整理一些我在实际使用中高频遇到的问题和对应的解法。这些不是教程手册里的标准答案，全是从真实排障现场里挤出来的经验。

6.1 常见问题速查表

特别备注一下断点打不上的情况：如果你在模板函数或内联函数里打断点，gdb 会提示创建 pending breakpoint，也就是“现在没有这个位置，将来可能匹配”。这种断点有时候真的不生效，所以函数被确认展开过再打断点更为靠谱。要用汇编断点，可以info address 函数名，拿到函数入口地址后break *地址硬断。

6.2 调试器之外：几个值得坚持的好习惯

调试器和测试一样，是效率工具。想真正玩好，我最深的体会反而是调试之外的事：

第一，程序最好保持“可调试”状态。Release 和 Debug 分开构建，不要图省事一直编译优化版本。Debug 版本里关掉内联、关掉优化，才能在 gdb 里看到真实逻辑而不是被优化器改写后的汇编。

第二，崩溃复现不是玄学。如果程序时好时坏，优先怀疑未初始化内存、数组越界、use-after-free，这三种 bug 用普通断点经常找不到，watchpoint + AddressSanitizer 才是正确的组合。

第三，学会看汇编不是浪费。gdb 里的layout asm或disassemble命令切换到汇编视图，能直接看到编译器把 C 代码变成什么样。遇到栈溢出、函数调用规范差异、编译器 bug 时，只有汇编能给你最终答案。虽然前期痛苦，但长远收益非常可观。

6.3 一套我日常最常用的调试开场白

每次接手一个新的 bug，我基本都按下面这套流程走一遍，效率高出硬猜太多：

gdb 程序名 (gdb) break main (gdb) run (gdb) next 20 (gdb) bt

先停在 main，然后用next快速平移执行到可疑代码附近，bt确认调用链。如果崩了，走 core 路线。如果数据不对，上条件断点。这套路径 95% 的问题都能在十分钟内锁死范围。

我个人在实际操作中越来越深的体会是：调试器的核心价值不在于“找 bug”，而在于帮你理解一个程序真正的运行方式。很多人依赖printf，其实等于一手遮着眼睛一手摸象。花两小时掌握 gdb 和 cgdb 的基本操作，之后的每一次定位问题，都是从“我可劲儿试”变成“我看一眼就知道大概在哪个位置”——这个转变值得每位开发者亲自体验一次。