又一次在凌晨两点的终端里盯着滚动日志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行号可能漂移、变量经常optimized out快发布前验证、复现线上问题无-g-O2基本无法源码级调试最快正式发布需单独保存符号文件所以我个人习惯是开发阶段一律-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 (buf0x0, len128) at app.c:42 #1 0x00000000004006a3 in process_packet (pkt0x7fff... ) at app.c:87 #2 0x00000000004007d2 in main () at app.c:112bt输出的栈帧顺序#0是崩溃时的当前帧往下是调用者。看的时候不要只盯着#0要往上追溯大概率真正出错的代码逻辑在调用链的某个中间位置。如果崩溃的地方在第三方库或者动态库里bt可能显示一堆内存地址。这时可以换frame N切换帧再用info locals看那一层的局部变量判断参数是否异常。3.3 bt、frame、info registers把现场翻个底朝天bt是第一步但有时候看不出问题。比如崩溃点在malloc内部或者在某处memcpy里你就算看到#0在_int_free里也没法直接知道是哪个业务模块调起来的。我的惯用步骤是(gdb) bt fullbt 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和stepnext别名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 128print每次都要手动敲。如果希望每次停下来自动打印某个变量用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: countwatch表示“变量值发生变化时中断”。程序一跑起来GDB会在每次count被写入时停下你就能看到是哪一行代码、哪个线程做了坏事。如果要监视读操作用rwatch读写都监视用awatch。硬件watchpoint的数量通常很有限x86下一般就4个。如果同时下了太多watchGDB会退化成软件模拟方式每执行一条指令都检查速度会慢几个数量级。所以不要开太多优先级最高的变量先盯。我处理那个缓冲区越界的模拟案例时就是用watch盯着目标结构体字段程序一崩栈直接指到了真正越界写入的那个函数。这个功能在“只改一个变量却找不到谁改的”场景里效率高到离谱。5.3 多线程调试thread apply all bt 与线程切换多线程程序崩溃之后bt只显示当前线程的栈这是新手常踩的坑。排查思路应该是先看所有线程的栈判断哪个线程是“真凶”(gdb) info threads (gdb) thread apply all btthread 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做远程调试是标准解法。目标板上启动gdbservergdbserver :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 nopassstop表示信号到达时GDB停下来nopass表示不要把这个信号转交给程序处理。这样段错误发生时GDB会先抓住你就能在程序自定义的处理逻辑之前看到原始现场。类似的还有handle SIGINT stop可以让CtrlC在调试器中生效而不是把中断信号直接传给被调试程序。6.4 调试器“卡死”与CtrlC的正确用法给程序下好断点continue之后程序跑了几分钟都没停第一反应是死锁了。但大概率不是死锁而是断点太宽每次命中都被忽略了或者线程太多时thread apply all bt的输出量太大看起来像卡住。遇到这种情况先按CtrlC中断到GDB提示符再用bt看当前线程栈用info threads看所有线程状态。如果CtrlC没反应我会再按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几乎不太需要再换别的工具了。