实习第三天，第一次用GDB调试C++程序

引言

实习第三天，mentor丢过来一个任务：“新提交的代码有点问题跑不通，你学着debug一下。”

我打开项目，编译、运行，屏幕上写着：Segmentation fault (core dumped)。

段错误是什么？不知道。怎么查？更不知道。在学校里 debug 全靠 printf ，往代码里插一堆 cout << "here"，然后重新编译、运行、看输出……反复十几次才勉强定位到问题。

但这次不一样——项目代码几千行，编译一次半分钟，printf 根本行不通。

这时候就需要借助gdb调试来帮助定位问题。

📌 第一部分：准备工作——让程序可以被调试

这是新人最容易踩的坑：编译的时候没加 -g 参数，进 GDB 只能看到一堆地址，看不到源码和变量名。

GDB 调试需要“调试信息”，相当于给程序附上一张“地图”——哪行代码对应哪条指令、变量名叫什么、存在哪个地址。不加 -g 编译出来的程序就是一张没有地名的空白地图。

正确的编译方式：

bash
g++ -g -o myapp main.cpp

如果优化影响调试，可以加上 -O0 关闭优化。

📌 第二部分：新人最常用的三个GDB操作

第一个操作：run——跑起来再说

启动 GDB：gdb ./myapp
然后输入 run（或简写 r），程序开始运行。

如果是段错误，程序崩溃时 GDB 会自动停住，告诉你崩溃的位置。

第二个操作：break——在关键位置挺住

在怀疑有问题的函数或行号上设断点，程序跑到那里就会停下来：

bash
break main        # 在 main 函数入口停
break 42          # 在第 42 行停
break myFunc      # 在 myFunc 函数停

第三个操作：print & backtrace——看变量、看调用栈

程序停住之后，最常用的两个命令：

bash
print var_name    # 看变量的值（可简写为 p）
backtrace         # 看函数调用栈（可简写为 bt）——谁调了谁，一路追溯到 main

📌 第三部分：进阶操作——让调试更高效

记录几个很实用但不太难的操作：

watch 监视变量：变量值被修改时自动停住，适合排查“谁把我这个变量改了”

continue：跑完当前断点，继续到下一个断点

step vs next：step 会进入函数内部，next 会直接执行完函数不进去

---

给自己的一些提醒事项：

• 编译时永远加 -g，养成习惯

• 别怕黑框框-，GDB 的命令就那么几个

• 记不住命令没关系，help 命令随时可以看帮助