1. GDB调试入门为什么需要它第一次遇到程序崩溃时我盯着黑屏的终端手足无措。直到同事告诉我用GDB看看core文件吧——这个建议彻底改变了我调试代码的方式。GDB就像程序员的X光机能透视运行中程序的每一处细节。想象你正在开发一个电商系统凌晨三点服务器突然崩溃只留下一个core.12345文件。这时候GDB能帮你快速定位到是数据库连接池的指针越界还是订单处理线程的死锁问题。我经历过太多这样的深夜救火GDB总能让我在老板发现前解决问题。2. 启动GDB的四种实战姿势2.1 调试新程序最基础的起手式gdb ./your_program这行命令我每天要敲几十次。但新手常犯的错误是忘记编译时加-g参数导致看不到源码信息。记得用gcc -g -O0 main.c -o debug_me上周我调试一个内存泄漏时就因为用了-O2优化变量值显示不全。血的教训调试阶段务必使用-O0。2.2 分析崩溃现场core文件调试gdb ./crash_program core.1234core文件就像程序的事故黑匣子。有次线上服务崩溃通过core文件发现是JSON解析库遇到畸形数据时assert失败。关键要确保执行ulimit -c unlimited开启core dump/proc/sys/kernel/core_pattern设置正确路径2.3 调试运行中的服务不重启的优雅方案gdb -p 12345当你的Nginx服务出现CPU跑满时直接attach到worker进程比重启服务优雅多了。记得先用ps -ef | grep nginx找对进程ID。我常用组合拳(gdb) bt full # 查看完整调用栈 (gdb) info threads # 检查所有线程状态2.4 带参数启动复杂环境的调试技巧gdb --args ./server --port 8080 --config dev.cfg调试带命令行参数的程序时这个技巧能保持参数传递链完整。上周我就用这个方法定位到一个参数解析bug——某个bool参数被意外传入了字符串。3. GDB核心调试操作手册3.1 控制程序执行流start在main函数开始处暂停run全速运行缩写rnext单步跳过nstep单步进入suntil运行到指定行有次调试多线程竞态条件我配合next和step发现了两个线程同时修改全局变量的危险操作。记住(gdb) display var1 # 每次暂停都显示变量值 (gdb) watch var2 # 变量被修改时中断3.2 查看与修改数据(gdb) p *(array10) # 打印数组前10个元素 (gdb) p/x var # 十六进制显示 (gdb) set var5 # 运行时修改变量调试加密算法时x/32bx buf命令帮我发现AES密钥被意外覆盖。对于复杂结构体试试(gdb) p *this-member-submember3.3 多线程调试技巧(gdb) info threads (gdb) thread 2 # 切换到线程2 (gdb) bt # 查看该线程调用栈上周排查死锁时我通过thread apply all bt发现两个线程互相等待互斥锁。关键命令(gdb) set scheduler-locking on # 锁定当前线程4. 安全退出与日志管理4.1 优雅退出的三种方式quit或q标准退出exit同quit部分旧系统不支持CtrlD快速退出重要提示调试远程进程时务必先detach再退出否则会导致目标进程被终止。我有次不小心kill了线上Redis换来一次事故报告。4.2 日志记录实战(gdb) set logging file debug.log (gdb) set logging on (gdb) bt full (gdb) set logging off这个技巧帮我解决了无数在我机器上正常的问题。把GDB输出发给同事看比口头描述有效十倍。进阶用法(gdb) pipe info registers | grep eax # 过滤关键寄存器5. 真实案例内存泄漏排查记上个月我们订单服务出现内存缓慢增长。通过GDB我最终定位到是MQ消费者忘记释放消息体。关键步骤在疑似泄漏点设置断点(gdb) b OrderService.cpp:235检查堆内存分配(gdb) info malloc-history 0x7fffe00008c0对比多次内存快照(gdb) malloc_info snapshot1.xml最终发现是消息反序列化后没有调用free。整个过程用时2小时如果用printf调试可能要两天。