GDB调试到底有多神奇？程序崩溃再也不怕了
你的程序又崩溃了？
好不容易写完的代码，一运行就报"段错误"，这种抓狂时刻程序员都懂。这时候就该请出调试界的 *** ——GDB了！这玩意儿可不是什么新出的奶茶品牌，而是能让你的代码"开口说话"的神器。今天咱们就手把手带你解锁GDB的隐藏技能，保准让你从两眼一抹黑变成调试小能手。
一、GDB不是玄学，是科学
很多人觉得用命令行调试像在玩密室逃脱，其实GDB就是个"代码翻译官"。它能让你暂停程序运行，挨个查看变量状态，就像给程序做CT扫描。记住这三个核心功能：
• 按下暂停键：在任意位置设置断点
• 慢动作播放：逐行查看代码执行过程
• 现场直播：实时查看内存和变量变化
举个栗子，你写了个计算器程序，结果除法老是报错。用GDB在除法函数前设个断点，运行到这里时输入print 除数变量，立马就能看到是不是有零值混进来了。
二、准备工作别偷懒
想用GDB调试，得先给程序"装个行车记录仪"。编译时必须加上-g参数，就像：gcc -g test.c -o test
这个参数会把代码位置、变量名等信息打包进程序。之前有个哥们忘了加这个参数，对着一堆内存地址发呆了俩小时，最后发现是编译选项没搞对，你说冤不冤？
三、新手必会的五个救命指令
- 启动调试：
gdb 你的程序名（比如gdb test） - 设断点：
b main（在main函数开始处暂停） - 开跑程序：
r（就像踩油门） - 走你下一步：
n（不钻函数）或s（钻进去看） - 查户口：
p 变量名（随时查看变量值）
举个真实案例：小明写了个循环求和程序，结果总和老是少1。用GDB在循环里设断点，每次循环用p i查计数器，发现是从0开始计数导致的边界问题，改个初始值就搞定了。
四、高级玩家这样玩
• 条件断点：b 行号 if 变量==值（比如当计数器到5时暂停）
• 内存侦探：x/10x 地址（查看指定地址的16进制内容）
• 回溯案发现场：bt（显示函数调用栈，像破案时的监控回放）
有次我碰上个指针乱飞的bug，用watch 指针变量设置观察点，只要指针被修改就暂停，最后逮到是个野指针在搞鬼。
五、常见翻车现场急救
场景1：程序突然崩溃
输入bt查看崩溃时的调用栈，配合frame 数字切到具体栈帧，再用p 变量查看当时的数据状态。就像上周同事的程序崩溃，发现是空指针访问，一查原来是某个函数没判空。
场景2：内存泄漏
虽然GDB不直接检测内存泄漏，但可以通过info proc mappings查看内存映射，对比不同时段的内存占用变化。有次发现某个函数每次调用都多占4KB内存，原来是忘记释放malloc的空间。
六、那些年我踩过的坑
• 用优化编译选项（-O2）会导致行号对不上，调试时记得用-O0
• 指针显示为地址时，用p *指针才能看到指向的值
• 多线程调试记得用info threads查看线程状态，不然容易跟丢
有个经典案例：调试时变量值显示""，原来是开了编译器优化，重新用-g -O0编译就正常了。
个人观点时间
用了这么多年GDB，最深的体会是：调试就像破案，GDB就是你的放大镜和指纹采集器。新手别被命令行吓到，其实它比图形界面更直接。记住，会写代码的是程序员，会调试的才是工程师。下次遇到bug别急着百度，先打开GDB跟你的代码好好聊聊吧！