GDB调试全攻略：从core文件到多线程，一次讲清C/C++排查思路

又一次在凌晨两点的终端里盯着滚动日志，printf打印了快二十行，还是不知道结构体里的那个字段是被谁写坏的。这种场景，写C/C++的人多少都经历过。后来我给自己定了个规矩：遇到内存被改、偶发崩溃、指针越界这类问题，第一件事不是继续加日志，而是把现场用core文件保下来，再用GDB调试还原调用栈。GDB调试是Linux环境下绕不开的基本功，不管你是刚毕业写第一段实习代码，还是维护一个跑了好几年的老服务，这套能力都值得花时间系统过一遍。这篇文章我就把编译、断点、core分析、多线程调试这条完整链路，以及这几年攒下的实际操作经验，一次整理出来。

1. 从一次深夜崩溃说起：为什么GDB调试仍是绕不开的基本功

1.1 printf大法走到黑，最后被一个core文件救了

大多数新手第一次接触调试手段，用的都是printf。这个方案不是不能用，但它的效率瓶颈非常明显：改代码、重新编译、复现、观察、再改，一个循环下来至少几分钟。如果问题是概率性的、需要跑几个小时才能复现，那printf大法基本等于碰运气。

更麻烦的是，printf本身可能会改变程序的时序。有些偶现问题，加了打印就不崩，去掉打印就崩，这其实是日志导致的时序偏移。你通过printf拿到的那点信息，往往是问题发生之后残留的“假象”，而不是问题本身。我有一次排查一个网络服务的内存问题，printf打出来的值看起来都是合理的，但程序就是会在某个copy时崩溃。最后靠core文件里的调用栈，发现真正的问题在另一个线程里写越界了，和日志看到的那段代码根本不在一条线上。

1.2 命令行的GDB到底比IDE调试器强在哪

很多刚入行的同事会用VSCode或CLion的图形化调试界面，点几个按钮就能设断点、看变量，确实方便。但图形界面的调试器，底层调用的很多还是GDB，只是把命令封装成了按钮和面板。直接学GDB的好处在于：

• 你理解的是底层机制本身，而不是某个IDE的交互习惯；
• 服务器上、容器里、嵌入式设备上未必有图形界面，GDB是唯一通用选项；
• 生产进程卡死或异常时，你可以用gdb -p PID直接附加进去看现场，这个操作在纯图形环境里几乎做不到；
• 看日志和看内核时，很多第三方工具（比如崩溃分析），最终输出还是要靠GDB来读取和解释符号信息。

所以，IDE可以作为日常开发的辅助，但GDB命令行这个看家本领，值得花时间把它练扎实。搞明白GDB怎么工作，图形界面里的那些按钮对你来说反而成了“可预测”的操作。

2. 编译期就要为调试铺路：-g参数、优化等级与调试信息的那些事

2.1 -g真正给程序加上了什么

很多人知道编译要加-g，但不知道加-g到底发生了什么。-g的本质是在生成的ELF文件里写入调试信息，主要是符号表：函数名、变量名、源码行号和机器指令地址之间的映射关系。没有这套映射，GDB拿到一堆寄存器地址和栈内容，根本不知道对应源码里的哪一行，bt打出来的全是??。

需要注意，-g不会改变程序的运行逻辑，也不会让程序变慢太多，它只是增加了一些文件体积和工作内存。所以日常开发调试，不要省这个选项。我见过有人担心“加了-g影响性能”，把调试信息去掉了，结果程序崩溃时GDB看不了任何源码级信息，排查效率直接回到石器时代。

2.2 优化选项杀掉变量：-O2下断不到变量的真相

调试体验的分水岭，其实不在-g，而在优化等级。用-g -O0编译的调试版本，行号和变量几乎一一对应，断点很听话。但换成-g -O2之后，你会在GDB里看到很多“奇怪”的现象：

• 断点命中位置比源码行号往后偏几行；
• 某个局部变量明明还在用，但print提示value optimized out；
• 函数被内联了，bt显示调了几层的函数其实没进栈；
• next单步时一次跳过了好几行代码。

原因是优化器为了性能，会重排指令、复用寄存器、内联函数、把局部变量直接映射到寄存器。源码行号和指令地址的对应关系，在优化之后变得非常“稀疏”甚至错位。这并不全是GDB的问题，而是二进制本来就不是照着源码逐行执行的。

所以我个人习惯是：开发阶段一律-g -O0，性能问题另说；需要模拟上线环境跑长稳时，才用-g -O2编一个版本，出了问题再靠core文件分析。

2.3 发布版本也要保留调试符号

这条经验是我吃过亏之后才养成的习惯。曾经有一次线上服务崩溃，现场保留了core文件，但发布包是strip且没带-g的，GDB加载core之后全是十六进制地址，压根没法看调用栈。最后折腾了大半夜，重新拉代码、用相同版本重新编译才勉强有了符号信息。

正确做法是发布时做两步处理：先用objcopy --only-keep-debug把调试符号单独导出一个文件，再把可执行文件里的符号strip掉。线上崩溃时，用GDB同时加载可执行文件和调试符号文件，照样能还原完整调用栈。具体命令大概是：

objcopy --only-keep-debug app app.debug objcopy --strip-debug app app.release

排查线上问题时：

(gdb) symbol-file app.debug

这样既有小体积的生产二进制，又保留了崩溃现场的可追溯性。

顺便说一句，调试信息在Linux ELF文件里通常采用DWARF格式存储。GDB能读懂DWARF，才能把地址映射回源码行。理解这个背景之后，你就明白为什么有些动态库符号不匹配时，GDB会提示“找不到abi版本”或“解码失败”之类的信息了。

3. 段错误不用愁：core dump配置与调用栈还原的完整流程

3.1 生成core文件的环境配置

程序崩溃时，操作系统默认会生成一个core文件，也就是进程崩溃瞬间的内存镜像。但很多环境下core文件默认是关闭的，或者被系统拦截了。排查段错误前，先把这一步配置好。

临时打开当前shell的core生成限制：

ulimit -c unlimited

这只影响当前终端会话。如果想更持久，可以写在~/.bashrc之类的位置。然后看内核把core文件写到哪：

cat /proc/sys/kernel/core_pattern

有些发行版会把core文件交给systemd-coredump管理，此时core文件不会直接出现在崩溃目录，要用coredumpctl list和coredumpctl gdb来调取。如果不希望绕这么大弯，可以把core路径直接指到一个固定目录：

echo '/tmp/core.%e.%p' > /proc/sys/kernel/core_pattern

%e是程序名，%p是进程PID，这样每次崩溃后/tmp/core.程序名.PID就是原始core文件。切记在分析完现场之后再做任何操作，不要动这个文件。

3.2 用GDB加载core文件的三步走

拿到core文件后，排查经典三连：

gdb ./app /tmp/core.app.12345

进入GDB界面后，第一件事是bt看调用栈：

(gdb) bt #0 0x0000000000400560 in write_data (buf=0x0, len=128) at app.c:42 #1 0x00000000004006a3 in process_packet (pkt=0x7fff... ) at app.c:87 #2 0x00000000004007d2 in main () at app.c:112

bt输出的栈帧顺序，#0是崩溃时的当前帧，往下是调用者。看的时候不要只盯着#0，要往上追溯，大概率真正出错的代码逻辑在调用链的某个中间位置。

如果崩溃的地方在第三方库或者动态库里，bt可能显示一堆内存地址。这时可以换frame N切换帧，再用info locals看那一层的局部变量，判断参数是否异常。

3.3 bt、frame、info registers：把现场翻个底朝天

bt是第一步，但有时候看不出问题。比如崩溃点在malloc内部，或者在某处memcpy里，你就算看到#0在_int_free里，也没法直接知道是哪个业务模块调起来的。

我的惯用步骤是：

(gdb) bt full

bt full会额外打印每个帧的局部变量，信息量比bt大得多。接着用：

(gdb) frame 2 (gdb) info locals (gdb) info args

看是哪一层把异常数据传下来的。如果再狠一点，info registers看寄存器值，x/16gx 0x7fff***直接看栈内存内容，基本能把现场翻个底朝天。

3.4 一个缓冲区越界的真实排查思路复盘

我之前处理过一个模拟场景：一个服务进程每隔几秒崩溃一次，bt看到的崩溃点在一个字符串拷贝函数里，而传入的源指针是个无效地址。看到这个栈，直觉是上游调用方传错了指针。

但用frame 1看上一层参数时，发现从逻辑上讲这一段数据应该没问题。真正可疑的是这个地址本来指向的是一块“看起来还没被释放”的内存。于是我在GDB里单独分配一块更大的临时缓冲，把代码里的越界写操作隔离验证，最终确认是某个模块在操作结构体数组时，没有严格校验下标，写越界把相邻结构体的指针字段覆盖了。崩溃点离真正的越界代码隔了好多次赋值，单看bt永远找不出元凶。

这种问题，bt只能告诉你“在哪崩的”，再往前溯源就得配合watchpoint或者内存布局分析。这个场景我在后面第5章会展开讲，因为它是GDB那些“高级功能”发挥价值最典型的地方。

4. 断点、单步、变量查看：GDB日常调试的完整链路

4.1 启动GDB的三种方式与适用场景

GDB启动不外乎三种形式：

gdb ./app

最常见的开发调试方式，启动后程序还没跑，先设好断点再run。

gdb ./app /tmp/core.app.12345

加载core文件分析崩溃现场，参数顺序是先程序后core，注意别写反。

gdb -p 12345

附加到运行中的进程。生产环境进程卡死、还是活着但行为诡异时，这个命令很实用。需要系统允许ptrace，普通用户对自己的进程通常没问题。附加之后可以看所有线程栈，也可以临时打断点观察。用完记得detach退出，别把进程一直挂在那儿。

4.2 断点设置：行号、函数名、文件行号、地址

设断点最无脑的方式是按行号：

(gdb) break app.c:42 (gdb) break 42

当前文件直接写行号即可。更推荐带上文件名，因为多文件工程同名行号不会混。按函数名设断点更抗代码变更：

(gdb) break process_packet

对于宏展开、模板实例化或者反汇编调试，可以直接在指令地址下断点：

(gdb) break *0x400520

断点管理用info breakpoints查看，disable 1临时关掉，enable 1恢复，delete 1删除。多个断点编号对应不同位置，注意区分。

我个人的习惯是：先在入口函数放一个断点，确认程序跑起来之后，再设目标断点。因为直接设一个深埋代码里的断点，如果程序路径没走到就白等半天了。

4.3 next与step、finish与until：单步调试的进阶控制

新手最容易混淆的是next和step：

• next（别名n）：执行一行，不进入函数内部，把整个函数调用当作一步；
• step（别名s）：执行一行，遇到函数调用会跟进去。

一行代码里有多个函数调用时，next和step的差异会被放大。比如这行：

result = parse_header(buf) + parse_body(buf);

next会把整行当成一个整体执行掉，而step会先进parse_header，执行完再出来，想继续看第二个函数还得再step。如果你只想跟其中某个函数，可以先next跳过，再在目标函数处单独下断点，或者用finish先跑完当前函数返回调用处。

finish（别名fin）是“执行完当前函数并返回”，非常适合从函数里快速跳出来。until 20的意思是继续执行直到源码第20行，常用于跳过循环体的一部分，比反复按next高效得多。continue（别名c）则是继续运行到下一个断点或程序结束。

4.4 print与display：查看变量和内存的姿势

print是查看变量的核心命令。不需要写全名，可以用表达式：

(gdb) print x $1 = 7 (gdb) print &x $2 = (int *) 0x7fffffffe3dc (gdb) print list[4] $3 = 128

print每次都要手动敲。如果希望每次停下来自动打印某个变量，用display更省事：

(gdb) display count 1: count = 1024

之后每次断点命中，GDB都会自动打印一遍。排查循环问题时，display加continue之王道组合，比反复手动print舒服太多。

想看局部变量全集，用info locals；要看某个结构体的类型定义，ptype直接显示结构体字段。这些都是调试中高频使用的命令。再往上一点，x/16gx 地址可以按十六进制查看一段内存，调试指针和越界问题时配合寄存器使用，效果奇佳。

5. 条件断点、watchpoint与多线程调试：高频进阶场景实战

5.1 条件断点在循环里精确命中

循环跑一万次只处理特殊值，你不想按断点按一万次。条件断点解决的就是这个需求：

(gdb) break app.c:45 if i == 9999

这行命令表示在第45行停下，但条件是i == 9999。每次执行到第45行，GDB都会对条件求值，条件成立才会真正中断。条件里可以写复杂的逻辑表达式，比如if pkt->type == 2 && pkt->len > 512。

注意一点：条件断点的表达式依赖于符号和变量处于当前作用域。如果断点位置所在函数还没执行到，或者变量被优化掉了，GDB会提示无法求值。所以条件断点最好在程序真正跑到那附近之后再设置。还有，条件断点的效率比普通断点低，因为每次都要执行表达式求值。在非常热点的循环里，如果条件太复杂，程序会明显变慢。

5.2 watchpoint抓“偷偷改变量”的元凶

有些bug极其恶心：一个变量的值在某个地方被改成了异常值，但调用链上没有任何一处看起来像凶手。这种情况，与其一个个断点排查，不如直接让GDB盯着这个变量：

(gdb) watch count Hardware watchpoint 2: count

watch表示“变量值发生变化时中断”。程序一跑起来，GDB会在每次count被写入时停下，你就能看到是哪一行代码、哪个线程做了坏事。如果要监视读操作，用rwatch；读写都监视，用awatch。

硬件watchpoint的数量通常很有限，x86下一般就4个。如果同时下了太多watch，GDB会退化成软件模拟方式，每执行一条指令都检查，速度会慢几个数量级。所以不要开太多，优先级最高的变量先盯。我处理那个缓冲区越界的模拟案例时，就是用watch盯着目标结构体字段，程序一崩，栈直接指到了真正越界写入的那个函数。这个功能在“只改一个变量却找不到谁改的”场景里，效率高到离谱。

5.3 多线程调试：thread apply all bt 与线程切换

多线程程序崩溃之后，bt只显示当前线程的栈，这是新手常踩的坑。排查思路应该是先看所有线程的栈，判断哪个线程是“真凶”：

(gdb) info threads (gdb) thread apply all bt

thread apply all bt会把每个线程的调用栈都打印出来。看到某个线程栈里正好停在pthread_mutex_lock，那多半是在等锁，而正在持锁的线程如果在写坏内存，问题就清楚了。

切换线程用thread N，其中N是info threads里的编号。单独给某个线程下断点也是常用操作：

(gdb) break app.c:88 thread 3

这会只在线程3命中这个断点。如果单步调试时不想被其他线程的断点干扰，可以打开set scheduler-locking on，锁住其他线程，让正在调试的线程单独走。真实生产环境里，我建议先thread apply all bt看全貌，再决定锁不锁线程，否则容易陷入“只缘身在此山中”的盲区。

5.4 gdbserver远程调试：嵌入式项目的救命稻草

嵌入式板子、ARM开发板上不方便直接装调试器，或者目标进程不适合直接附加，这时候用gdbserver做远程调试是标准解法。

目标板上启动gdbserver：

gdbserver :2333 ./app

宿主机上启动GDB：

(gdb) target remote 192.168.1.10:2333

连接之后，所有的断点、单步、变量查看操作都是在宿主机上进行的，实际效果和本地调试几乎一样。唯一的硬性要求是：宿主机上加载的可执行文件必须和目标板上运行的是同一个版本，连编译选项都要一致。最好在编译完成后用某种方式记录可执行文件的构建标识，避免两边二进制对不上导致行号错乱、符号地址错位。我经历过一次两边代码“大概相同”带来的诡异现象：断点能下，但每次命中的行号都偏，排查半天才发现是目标板的二进制不是最新构建的，教训深刻。

6. 我在项目里用GDB踩过的坑和攒下的习惯

6.1 -O2下断点点错行的坑

有一次排查一个性能问题，断点设在第86行，实际命中时却停在了第84行。我一开始以为自己记错位置了，后来发现是优化导致指令重排。有了这次经历，我对优化版本里的“源码行号”不再绝对信任，而是以汇编指令和寄存器状态为准。如果你必须在优化版本里调试，建议很关注info line 86实际映射到了哪个地址段，必要时直接break *地址。

6.2 生产环境没有符号，bt全是??的坑

前面讲过objcopy --only-keep-debug的做法，这里再补充一条操作技巧：把调试符号文件单独保存之后，最好同时在版本描述里记录对应的源码分支和提交号。线上问题分析时，只有符号文件还不够，如果源码已经迭代了好几个版本，行号对应关系同样会错乱。我现在做发布时，会专门建一个带日期和提交号的目录，把可执行文件、调试符号文件、源码分支说明打包归档。这种做法让后续的线上问题复核省了无数时间。

6.3 信号处理干扰调试器：handle命令的使用技巧

程序自己用signal()注册了 SIGSEGV 处理函数，想在崩溃前打印日志。这个设计听起来很合理，但对调试者来说是个大坑：操作系统捕捉到段错误会先交给程序的信号处理器，GDB默认把信号交给程序处理，你设的断点根本触不到，程序的信号处理函数反而先跑起来。

这时候用GDB的信号控制命令：

(gdb) handle SIGSEGV stop print nopass

stop表示信号到达时GDB停下来，nopass表示不要把这个信号转交给程序处理。这样段错误发生时，GDB会先抓住，你就能在程序自定义的处理逻辑之前看到原始现场。类似的还有handle SIGINT stop，可以让Ctrl+C在调试器中生效，而不是把中断信号直接传给被调试程序。

6.4 调试器“卡死”与Ctrl+C的正确用法

给程序下好断点，continue之后程序跑了几分钟都没停，第一反应是死锁了。但大概率不是死锁，而是断点太宽，每次命中都被忽略了，或者线程太多时thread apply all bt的输出量太大，看起来像卡住。遇到这种情况，先按Ctrl+C中断到GDB提示符，再用bt看当前线程栈，用info threads看所有线程状态。

如果Ctrl+C没反应，我会再按Ctrl+\发送SIGQUIT强制退出，但这种做法会直接终止被调试进程，不建议作为第一选择。真正顺手的习惯是：调试之前先把不必要的断点删掉，有选择地设置断点范围；一个函数里断点下太多，只是给自己找麻烦。

6.5 在GDB里改变量和调用函数：跳过冗长复现的捷径

GDB不只能看，还能改。确认某个分支走不通时，可以直接改掉变量后再继续：

(gdb) set var count = 100 (gdb) call init_cache()

这样就不用为了走到某段代码而重编重启整个程序。尤其在后端长时运行的服务里，重启一次成本极高，GDB的set var和call几乎是唯一能在不退出程序的情况下“篡改现场”的手段。需要注意，call调用程序内的函数是有风险的：如果函数本身会崩，你的调试进程也会崩。所以只用来调用一些稳定性有把握的初始化或清理函数。

6.6 最后一件事：先把现场保住，再开始思考

现在回头看，调试这件事最大的“心法”其实是：发现问题后，第一反应不是抢着分析，而是先把现场冻结住。core文件里藏着崩溃瞬间的全部家底——所有线程栈、所有变量、寄存器、内存内容。有了这份现场，后面再怎么折腾都有底。我现在的流程是：ulimit打开、core_pattern设好、编译带调试符号、发布保留符号文件。这套准备工作做得越早，后面每一次故障处理的效率就越高。

还有一个使用习惯想分享：GDB里面敲help，其实内置帮助文档已经写得非常细致，很多命令的边边角角，查一下就知道。命令行支持Tab补全，互交时多按Tab能少打很多字。你也可以在~/.gdbinit里放一些自己常用的命令别名或默认设置，比如自动加载符号、开启历史记录这类。真正把GDB用顺手之后，你会发现在Linux下调试C/C++，几乎不太需要再换别的工具了。