前阵子帮同事排查一个线上崩溃程序跑了大半天才挂挂在哪一行完全看不出来日志里最后一条信息还离崩溃点十万八千里。折腾了半个下午最后上了GDB两分钟定位到一处野指针。从那之后我就一直在想Linux下做C/C开发的人GDB是早晚要迈过去的一道坎早点掌握它后面能省下无数加班的夜晚。这篇文章不是想给你罗列一大堆命令手册而是把我实际用GDB排查问题时最常用、最有效的那套东西整理出来包括编译期就得做对的准备、崩溃现场的分析思路、断点和单步的精髓、多线程调试的注意点以及几个教程里很少写的坑。无论你是刚接触Linux开发的新手还是写过一段时间但对GDB只停留在“会用start和next”阶段的人看完这篇应该都能直接上手解决实际项目里的问题。1. 为什么Linux下调试离不开GDB1.1 日志排查的边界很多人写程序习惯用printf遇到bug就打日志。日志确实有用尤其适合排查业务逻辑问题。但有一类问题靠日志很难搞典型的就是段错误、栈溢出、非法内存访问。这类崩溃偶尔复现甚至只在压力测试时出现你根本不知道在哪个函数、哪一条指令触发了它打再多的printf都是盲人摸象。还有数据竞争这类问题两个线程同时改一个变量日志顺序看起来完全正常但结果就是不对。这时候你需要的是逐行审视代码在内存里到底干了什么需要看到每一个变量的实际值、每一块内存的实时内容而GDB的核心价值就在这里它能让你把程序“暂停”在任意一个你关心的时刻然后你就能看清这个时刻的所有细节。我个人的习惯是逻辑问题先查日志查不到就用GDB跨过“靠猜加盲目打印”的阶段。实际项目里GDB解决频率最高的问题就三类——崩溃闪退、逻辑结果不正确、多线程跑飞每一类GDB都有成熟的调试套路。1.2 GDB到底能做什么GDB全名GNU Debugger是Linux平台上最主流的调试器。它的能力要从三个层面看控制执行断点、单步、继续运行到指定位置、跳过或进入函数观察现场打印变量、查看栈回溯、查看内存、查看寄存器、查看线程和进程状态修改现场运行时修改变量值、强制函数返回、跳过某段代码用这个能模拟各种边界条件我见过有人用GDB十几年就记住了三个命令break、run、print。这三个确实能解决一部分问题但如果你只知道这三个遇到断点打不上、变量被优化掉、多线程死锁、core文件解析不了的时候就会卡住。所以后面我会把常用的场景串起来讲不只是堆命令。注意不需要把GDB几百个命令都背下来真正的核心命令不超过二十个熟练使用它们已经能覆盖绝大多数调试场景了。2. 准备工作编译期就要做对的事2.1 -g参数决定了你调的是什么GDB调试时依赖调试信息来建立“源码行号 ↔ 二进制指令 ↔ 变量地址”之间的对应关系。要让GDB能告诉你“程序崩在第3个文件第27行”前提是编译时加了-g参数gcc -g -o demo demo.c-g会让编译器在二进制文件里生成一个调试信息段包含源码行号、变量名、函数名、参数类型这些元数据。没有这个信息GDB看到的全是十六进制地址和汇编指令虽然也能调但难度直接上升一个台阶。另外一个容易被忽视的参数是-g3。它比-g多包含宏定义信息如果你调试的程序里用到宏想用info macro查看宏的展开结果就得在-g后面加一个3。我的建议是项目调试版本统一用-g3编译成本差别不大。还有一点很多人忽略了编译器优化对调试体验的影响见下一节。2.2 优化选项与调试信息的恩怨编译时常用的优化选项有-O0、-O1、-O2。优化开得越高编译器的重排、内联、寄存器变量优化就越激进最终产出的机器码和你写的源码之间差异就越大。我用一个实际踩过的坑说明某个问题在-O0下正常、在-O2下必现于是我在发布版本上直接跑GDB想定位结果print某个局部变量提示“value optimized out”单步走的时候发现代码在odd跳步你明明在源码第10行执行完第11行之后居然跳到了第15行。这不是GDB坏了而是编译器把中间的计算过程优化掉了有些变量只存在于寄存器里甚至直接被常数替代掉了。所以我的建议很明确排查崩溃类问题时先用-O0编译一个调试版本问题在调试版本能复现就先在调试版本上定位如果问题只在-O2下复现也不要硬刚优化代码试着添加-fno-omit-frame-pointer保留栈帧指针并且在关键函数上用__attribute__((optimize(O0)))做局部关闭优化。记住一个原则先在未优化版本上把逻辑调试清楚再去分析优化版本的特殊行为而不是直接在高优化级别下硬调。还有一个参数值得了解-fno-stack-protector。有些发行版默认开了栈保护越界时程序会主动abort而不是崩在真正越界的代码里这有时会误导排查方向。定位栈溢出时先关掉它往往能看到更原始的崩溃位置。2.3 启动GDB的几种姿势GDB不仅仅是“gdb ./program”这一种玩法实际工作中我常用的有四种场景命令适用情况普通调试gdb ./demo程序能稳定复现问题传参调试gdb --args ./demo arg1 arg2程序依赖启动参数挂载进程gdb -p 23456程序在跑且不好重启分析coredumpgdb ./demo core.12345程序崩溃后有core文件挂载进程这个功能特别实用生产环境出问题不想立刻重启进程时可以用gdb -p加到进程上抓现场。但注意挂上去之后进程是暂停的别忘了在结尾用detach把它放掉否则进程就一直卡住了。分析core文件是我最推荐的崩溃排查方式后面第3节再展开聊。2.4 自动化批处理.gdbinit与-batch模式日常调试总有反复输入几条固定命令的场景比如启动后先设置断点、然后打印参数。你可以在当前目录或用户目录写一个.gdbinit文件GDB启动时会自动读取并执行里面的命令。下面是我的一个示例set pagination off set print pretty on set print thread-events offset pagination off很关键它关闭了GDB的分页提示否则输出一多就出现“---Type to continue”卡在那里批处理脚本里直接就没法跑了。还有一种用法是在脚本里跑非交互式调试。比如定时任务里程序崩了第二天想快速拿到栈直接用一行命令输出然后退出gdb -batch -ex run -ex bt --args ./demo-batch表示非交互模式逐条执行-ex参数指定的命令全跑完自动退出。我在写自动化测试脚本时经常用它批量检查崩溃栈不用人工干预。3. 核心调试实操从一个崩溃程序说起3.1 程序崩溃后第一件事看栈回溯先看一个能稳定复现段错误的例子后面就用它来演示GDB的核心操作。源码是这样的#include stdio.h #include string.h char *safe_strcpy(char *buf, const char *src) { if (src NULL) { strcpy(buf, unknown); } else { strcpy(buf, src); } return buf; } int main() { char buf[32]; strcpy(buf, abcdefg); safe_strcpy(buf, NULL); printf(result: %s\n, buf); return 0; }我故意让strcpy收到NULL指针编译运行后直接段错误。这种问题用日志几乎没法查因为你根本不知道哪个函数传进了NULL。用GDB复现的流程是gcc -g -O0 -o demo demo.c gdb ./demo进到GDB后输入run程序跑起来崩溃Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7e2b3c8 in __strcpy_sse2 () at ../sysdeps/x86_64/multiarch/strcpy-sse2.S:58这里GDB已经告诉你崩在strcpy的汇编实现里。但这还远远不够重要的问题是是谁调用了strcpy参数传进来的src到底是不是NULL此时输入bt也就是backtrace查看当前线程的函数调用栈(gdb) bt #0 0x00007ffff7e2b3c8 in __strcpy_sse2 () at ../sysdeps/x86_64/multiarch/strcpy-sse2.S:58 #1 0x0000000000401200 in safe_strcpy (buf0x7fffffffdf50 abcdefg, src0x0) at demo.c:9 #2 0x0000000000401245 in main () at demo.c:15这一下就清楚了。栈回溯会列出从崩溃时的最内层函数到最外层函数的完整调用链每一帧还附带关键参数值。你看第1帧里safe_strcpy的src0x0直接就露出来了NULL指针的元凶马上锁定。bt之后一般搭配的是frame命令切到指定栈帧然后查看局部变量(gdb) frame 1 #1 0x0000000000401200 in safe_strcpy (buf0x7fffffffdf50 abcdefg, src0x0) at demo.c:9 9 strcpy(buf, unknown); (gdb) info args buf 0x7fffffffdf50 abcdefg src 0x0记住这个流程化打法崩了之后先看bt拿到整个调用链再切frame到目标帧查看参数和局部变量。80%的崩溃问题靠这一步就能定位出原因。3.2 断点的正确打开方式崩溃排查只是GDB的一面另一面是主动出击程序还没崩但你知道某个函数可能有问题想在它被调用时停下来看看。这时候用break设置断点。GDB里断点的核心命令其实就几种break safe_strcpy # 在函数入口打断点 break demo.c:8 # 在源文件第8行打断点 break demo.c:8 if len 0 # 条件断点满足条件才暂停条件断点非常实用。比如一个循环跑一万次第9000次结果不对你不想被断点打断9000次直接写break demo.c:8 if i 9000程序会在i等于9000的时候才停下来。这就是硬件/软件断点加上条件判断的配合。还有一个我经常用的命令是tbreak临时断点只触发一次自动删除。比如只是想停在一个位置看一眼不想让断点残留用这个就很干净。查看和删除断点info breakpoints # 列出所有断点及其状态 delete 1 # 删除编号为1的断点 disable 2 # 禁用编号为2的断点保留位置 enable 2 # 重新启用实践中我见过有人把几十个断点全堆在代码里断点太多会互相干扰每个暂停都会检查一遍条件严重影响运行速度。我的习惯是一次只保留三到五个断点解决完一批马上删掉或禁用。3.3 单步执行next、step、until怎么选断点命中后最重要的是逐行看清程序的执行过程。GDB里三个最常见的单步命令长的很像但语义差别很大next执行当前行遇到函数调用直接跳过也叫“单步跳过”step执行当前行如果遇到函数调用就进去也叫“单步进入”until在循环里一直执行直到到达指定行号或退出循环用demo举例子。我在main函数第12行strcpy(buf, abcdefg)处打断点run进去后(gdb) next 13 safe_strcpy(buf, NULL); (gdb) next Program received signal SIGSEGV, Segmentation fault.第一次next执行完strcpy第二次next直接步入safe_strcpy的调用结果就崩了。注意next在遇到函数调用时是整体执行完再停到下一条语句的所以如果函数内部崩溃next会直接带着你看到崩溃现场。如果我想看safe_strcpy内部是怎么走的要用step(gdb) break demo.c:12 (gdb) run Breakpoint 1, main () at demo.c:12 12 strcpy(buf, abcdefg); (gdb) next 13 safe_strcpy(buf, NULL); (gdb) step safe_strcpy (buf0x7fffffffdf50 abcdefg, src0x0) at demo.c:5 5 if (src NULL) {step把你带进了safe_strcpy函数体内。之后第6行的strcpy(buf, unknown)如果真的执行又会二次步入库函数内部。如果想跳出当前函数回到调用者用finish(gdb) finish Run till exit from #0 safe_strcpy (buf0x7fffffffdf50 abcdefg, src0x0) at demo.c:5finish是“执行完当前函数然后停在返回处”非常常用尤其在盯着一个函数内部执行完之后的调用现场时。until的典型场景是循环。你想在一个循环里快速执行到某个位置但又不想一行一行next按几百次直接until demo.c:20就能一口气跑到第20行。注意使用step进入库函数时GDB经常会一头扎进printf、strcpy这类C库的内部实现里面全是汇编对排查业务逻辑没啥帮助。遇到这种情况直接finish跳出去或者干脆用next避免进入。3.4 变量、内存与寄存器看变量最常用的是print命令后面跟变量名或表达式(gdb) print src $1 (char *) 0x0 (gdb) print buf $2 0x7fffffffdf50 abcdefg (gdb) print/x 12345 $3 0x3039print的格式控制符很重要不同场景要用不同的格式p/x 按十六进制看指针和地址p/d 按十进制看整数p/c 按字符看字节p/s 按字符串看内容p *ptrcount 看指针指向的连续count个元素比如看到指针地址是0x7fffffffdf50怀疑它指向的内存被写坏了想看看它前16个字节的内容(gdb) x/16bx 0x7fffffffdf50 0x7fffffffdf50: 0x61 0x62 0x63 0x64 0x65 0x66 0x67 0x00 0x7fffffffdf58: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x000x61到0x67是abcdefg的ASCII码后面的0x00是被strcpy写入的字符串终止符。x命令的格式是x/长度格式单位大小 地址b是单字节、w是四字节、g是八字节。这个组合能帮你看清任意内存区域的实际内容排查越界写、内存覆写时是神器。查看寄存器用info registers调试汇编和栈问题时有用(gdb) info registers rip rsp rbp rip 0x7ffff7e2b3c8 rsp 0x7fffffffdf48 rbp 0x7fffffffdf60在实际调试里打印变量的优先级高于看寄存器后者主要用于底层汇编分析、函数调用约定排查这类场景。4. 多线程调试崩溃只是表象4.1 定位死锁和数据竞争多线程程序出问题时经常会发现单独的某个线程看起来都“正常”但整体结果不对。GDB提供了查看所有线程并切换线程的能力。用一个最简单的多线程自增程序演示两个线程同时对共享变量做自增缺少锁保护最终结果大概率小于2000。编译时注意加lpthreadgcc -g -O0 -o demo_thread demo_thread.c -lpthreadGDB里看到线程列表(gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff7dbc740 (LWP 23456) demo_thread main () at demo_thread.c:23 2 Thread 0x7ffff75bc700 (LWP 23457) demo_thread worker (arg0x0) at demo_thread.c:10带*号的是当前调试线程。切换到线程2(gdb) thread 2 [Switching to thread 2 (Thread 0x7ffff75bc700 (LWP 23457))]注意切换线程后GDB会暂停在那个线程当前执行的指令上。接下来可以用bt查看这个线程的栈用info locals看它的局部变量。要同时看所有线程的栈用(gdb) thread apply all bt这条命令在定位死锁时特别管用。死锁的典型特征是多个线程各自卡在不同的锁等待上你用thread apply all bt能看到每个线程停在哪个锁函数里比如线程A卡在pthread_mutex_lock占有锁X线程B卡在pthread_mutex_lock占有锁Y而A在等Y、B在等X死锁闭环立刻显现。确认了数据竞争下一步就要靠watch命令监视某个变量何时被修改(gdb) watch shared Hardware watchpoint 2: shared (gdb) continue每当shared的值发生变化GDB就会暂停并且打印先前的值和新的值。连续watch几次你就能看到两个线程交错修改shared的现场数据竞争引发的丢更新操作就暴露出来了。4.2 如何跟踪fork出的子进程多进程程序用fork创建子进程很常见GDB默认只跟踪父进程子进程会脱离调试。如果你想调试子进程需要在fork之前设置set follow-fork-mode child set detach-on-fork offset follow-fork-mode child让GDB在fork后自动跟随子进程set detach-on-fork off让父进程继续保持被调试状态两个进程都在GDB控制下可以用info inferiors命令查看和管理多条进程上下文。这里有个经验多进程调试时建议先搞清问题出在哪个进程再决定跟着谁。不加区分地同时调试两个进程会频繁被另一个进程的断点打断调试效率反而暴跌。实际项目里我一般先只跟父进程如果确认问题在子进程再切过去。4.3 多线程调试的个人经验多线程调试容易踩的坑比单线程多得多分享几个压箱底的经验。第一个是线程切换和断点之间的配合。默认情况下你在主线程设置断点后运行只有主线程命中断点会暂停其他线程命中相同断点也会各自暂停。但有的时候你只想让指定线程停下来set scheduler-locking on这条命令开启调度锁GDB暂停一个线程后其他线程也跟着暂停不会被单独放跑。在排查数据竞争时这个尤其重要否则你在观察线程A时线程B却在后台疯狂跑变量内容一直在变你根本看不准。第二个是开线程事件开关。GDB默认会在每个线程创建和退出时打印一堆事件信息调试复杂程序时非常刷屏set print thread-events off第三个是别急着在怀疑的代码上单步。多线程程序单步执行会影响时序很多时候多线程bug一旦进入单步就复现不出来了。我的经验是先用日志和perf工具缩小范围明确到具体几行代码后再把GDB的断点精准设在那几行上用continue让程序高速跑到断点附近而不是从main开始一步步走。5. 常见问题与排查技巧实录5.1 常见问题速查表把大家问得最多、我自己也踩过的场景整理成一个表格按图索骥用起来非常方便现象常见原因排查手段崩在库函数里参数非法多为空指针bt看调用栈frame切到上层print变量显示optimized out编译优化把变量优化掉了改用-O0编译或专项关闭优化断点打在函数上不生效断点处被编译器内联掉改成在文件行号打断点程序一run就退出常因找不到动态库或参数错误用info sharedlibrary和set args检查core文件gdb读不出来生成core时没保存可执行文件确保core和对应可执行文件版本匹配多线程加断点后程序卡死断点命中后进入锁等待用scheduler-locking onbt看锁状态崩溃在-O2下必现-O0正常优化改变了执行路径单独用-fno-omit-frame-pointer复现分析5.2 调试时我见过最坑的几个现象先说“变量被优化掉”。这个在大型代码库里特别常见尤其release版本。你明明在源码里能看到那个变量print却告诉你optimized out。我第一次遇到时以为GDB坏了后来才明白是编译器把变量直接揉进了表达式里根本没有分配内存位置。排查思路是一不要在高优化级别下浪费时间先换-O0二不要指望所有变量都非得能print改成在函数入口用info args看参数或者特意留一个全局变量记录关键状态。再说“断点打不上去”。有的时候你在函数名上breakGDB却提示“No symbol table is loaded”或者断点设到了一个内存地址但永远不命中。最常见原因是函数被编译器内联了断点实际对应不到入口。解决办法很简单要么在源码行号上打断点要么临时用noinline属性阻止内联__attribute__((noinline)) static int helper(int x) { return x * 2; }第三个坑是core文件版本不匹配。GDB要求core文件和产生它的可执行文件完全匹配否则bt出来全是“No symbol table info available”这种鬼话。很多人程序崩了只把core拷回来不拷可执行文件结果根本看不出什么问题。正确的搬家姿势是core文件和对应版本的二进制一起打包拿回来。5.3 一些提升效率的小技巧除了大块的调试技能还有几个小而美的技巧能显著提升日常使用体验。反向调试。GDB支持记录程序执行轨迹然后反向运行命令是record break demo.c:13 run reverse-continuerecord开启记录模式程序运行过的每一条指令都会被记录下来然后你可以reverse-continue往回走从崩溃点一步步倒着查它是从哪里来的。这个功能对排查“变量为什么变成这个值”这类问题极其好用。代价是record模式运行速度明显变慢而且指令记录量大了很吃内存适合小范围复现场景。TUI界面。GDB自带一个字符界面模式layout src进入后屏幕会分成两个区域上面显示源码下面显示命令区光标跟着当前执行行走比纯命令行敲list直观一百倍。用CtrlXA可以在TUI模式和普通模式间切换。gdbinit一句话配置。我每次新建调试环境都会写这么三句set pagination off set confirm off set print pretty onset confirm off省掉了删除断点、退出GDB时的确认提问批量操作时能省不少事set print pretty on让结构体打印时按成员换行排列看复杂数据结构清晰得多。还有print自定义美化。调试C项目时可以给std::vector、std::map这些容器配pretty-printer让print查看STL容器内容变得直观可读。我们在某大型项目里给了自定义了十几条pretty-printer的配置排查复杂数据结构问题全靠它否则纯靠看地址和内存效率不可同日而语。最后再说说core dump的正确打开方式。Linux上默认不生成core文件需要设置ulimit -c unlimited这个命令最好写进shell的配置文件里否则新开一个终端又得重新设置。我建议是在开发环境的日常启动脚本里加上这一行然后程序崩溃后会生成core.pid文件。等到问题发生时直接用gdb -c core文件单步回放崩溃现场。这种方式比启动GDB现跑一遍程序高效得多而且不会改变程序的运行时序多线程程序的崩溃现场也更真实。我在实际项目里还试过给GDB写一点Python扩展。GDB本身就是支持Python的你可以自定义命令、创建断点脚本甚至解析日志自动定位可疑点。对简单场景来说这些可能有点杀鸡用牛刀但一旦接触复杂C系统尤其要批量分析多个崩溃现场时会写几条自定义脚本能节省的时间非常可观。写在最后的个人体会GDB真的是越用越离不开的工具。我自己刚学的时候也觉得命令又多又杂命令行上手成本高但真正用过几次把它解决掉实际问题后就再也回不去纯靠日志猜bug的状态了。重点是先把每个场景里最核心的那几个命令练熟崩溃看bt、断点看break、单步选next和step、变量看print、多线程看thread apply all bt跑通了这套基本流程你已经能应付一大半真实问题了。再往后想进阶的话值得研究的方向是反向调试、TUI界面、Python扩展和core文件自动化分析。尤其是把GDB接入项目的自动化崩溃检测流程那些在CI里被抓到的崩溃不用等人工介入就能自动拉出崩溃栈这对团队效率的提升是很明显的。最后给大家一个建议不要等出了问题才翻GDB手册找个周末拿自己以前的bug程序练一练把断点、单步、栈回溯、修改变量这四个基础流程走一遍。真正上手一遍之后你会发现它其实没有想象中那么难而且能帮你在未来节省出大量本来要消耗在深夜排查上的时间。