代码示例与验证记录

• examples/ex1-gdb-demo.c受控段错误程序（NULL 解引用，配合 ex2 的 gdb 批处理定位）✓ 已实测（gcc 15.2.0 + gdb 17.1 / MinGW-w64 x86_64 / Windows 11, 2026-08-15）
  编译：gcc ex1-gdb-demo.c -o ex1 -std=c11 -Wall -Wextra -Wpedantic -g -O0

  适用环境：LinuxWindows(MinGW)

  展开预期输出（实测）

  before crash
  

  差异说明：编译 0 警告；直接运行只打印 before crash 后崩溃——Windows 退出码 0xC0000005（访问违规）， Linux 显示 Segmentation fault (core dumped)。崩溃定位流程见 ex2；本程序为教学用受控 bug，不破坏环境

  完整源码见 /code 代码示例页

• examples/ex1-gdb-batch.txtGDB 批处理命令与实测输出（断点流程 + 崩溃定位流程）✓ 已实测（gdb 17.1 (GDB for MinGW-W64) / Windows 11, 2026-08-15）
  编译：在 ex1 编译产物目录执行文件内两条 gdb -batch 命令

  适用环境：LinuxWindows(MinGW)

  展开预期输出（实测）

  流程一（断点定位）：
  Breakpoint 1 at 0x14000171b: file ex1-gdb-demo.c, line 6.
  before crash
  Thread 1 hit Breakpoint 1, store (n=84) at ex1-gdb-demo.c:6
  $1 = 84
  #0  store (n=84) at ex1-gdb-demo.c:6
  #1  0x00007ff7c3a31764 in compute (n=42) at ex1-gdb-demo.c:14
  #2  0x00007ff7c3a317a9 in main () at ex1-gdb-demo.c:22
  
  流程二（崩溃定位）：
  Thread 1 received signal SIGSEGV, Segmentation fault.
  0x00007ff7c3a3172a in store (n=84) at ex1-gdb-demo.c:7
  #0  0x00007ff7c3a3172a in store (n=84) at ex1-gdb-demo.c:7
  #1  0x00007ff7c3a31764 in compute (n=42) at ex1-gdb-demo.c:14
  #2  0x00007ff7c3a317a9 in main () at ex1-gdb-demo.c:22
  

  差异说明：地址与线程号每次运行不同；compute(42) 先乘 2 再传给 store（故 store 内 n=84）。 本输出为 gdb 17.1 / Windows 11 本机实测；Linux 命令一致（把 ex1.exe 换成 ./ex1）

  完整源码见 /code 代码示例页

• examples/ex2-optimized-out.c-O2 优化对调试的影响（行号漂移与变量被消除，预期诊断现象）诊断示例（预期报错/警告）✓ 已实测（gcc 15.2.0 + gdb 17.1 / MinGW-w64 x86_64 / Windows 11, 2026-08-15）
  编译：gcc ex2-optimized-out.c -o ex2o2 -std=c11 -Wall -Wextra -Wpedantic -g -O2（编译成功；演示现象在 gdb 中）

  适用环境：LinuxWindows(MinGW)

  展开预期输出（实测）

  Breakpoint 1 at 0x1400030e9: file ex2-optimized-out.c, line 6.
  Thread 1 hit Breakpoint 1, main () at ex2-optimized-out.c:8
  8	    return sum % 5;
  $1 = <optimized out>
  $2 = <optimized out>
  

  差异说明：预期诊断现象（非编译错误）：断点打在循环内第 6 行，-O2 下实际命中第 8 行（行号漂移）； i 与 sum 均显示 <optimized out>（常量折叠后变量被消除）。对策：调试用 -O0 -g，发布才用 -O2。 本输出为 gdb 17.1 实测

  完整源码见 /code 代码示例页

• examples/ex3-core-dump-linux.txtcore dump 概念命令（Linux 专属；未执行，文档核对）概念讲解示例✓ 文档核对（非执行）· GDB 官方手册 + core(5) 文档核对, 2026-08-15
  编译：按文件内顺序在 Linux 终端执行（本机无 Linux，未执行）

  适用环境：Linux

  展开文档核对记录

  （概念说明，非实测输出）：
  配置 ulimit -c unlimited 后运行崩溃程序 → 生成 core 文件 →
  gdb ./ex1 core 回放崩溃现场 → bt 查看崩溃调用栈。
  core 路径与命名随发行版 /proc/sys/kernel/core_pattern 配置不同
  

  差异说明：本机无 Linux 未执行，命令按 GDB 官方手册与 core(5) 文档核对； Windows 对应物为 minidump/WER，机制不同，本章不展开

  完整源码见 /code 代码示例页

• ex-1-1-6-1.程序段错误崩溃后，在 gdb 里最有用的定位命令是？（单选）

  • A.run 崩溃后用 backtrace 找栈顶自己的代码
  • B.list 从头看代码
  • C.quit 重跑
  • D.help 查手册
  提交本题◌ 未作答

• ex-1-1-6-2.想在函数 store 被调用的那一刻暂停（而不是某一行），断点应该怎么打？（单选）

  • A.break store
  • B.break main
  • C.watch store
  • D.print store
  提交本题◌ 未作答

• ex-1-1-6-3.gdb 里 print i 显示 <optimized out>，最可能的原因是？（单选）

  • A.编译用了 -O2，变量被优化消除（本机实测）
  • B.变量名拼错了
  • C.程序没加 -g
  • D.gdb 版本太旧
  提交本题◌ 未作答

章节测验

实践任务

面试问题

• 线上程序崩溃了，现场没有调试器，你怎么定位？高频C/C++ · medium

  要点：用 core dump：配置 ulimit -c 后崩溃会留 core 文件，gdb ./prog core 回放现场，bt 看崩溃调用栈。

  核心思路是"事后回放"：崩溃时内核把进程内存现场写成 core 文件，之后任何时间用 gdb ./prog core 打开，bt 就能看到崩溃时的完整调用栈（等价于崩溃瞬间按下暂停）。 前提：① 编译发布版也要带 -g（调试信息可单独剥离给符号服务器，不影响性能）； ② ulimit -c unlimited 或按发行版配置 core_pattern。没有 core 时退而求其次： 日志 + 复现 + 二分注释定位。Windows 对应机制是 WER/minidump，思路相同。

  追问：

  • 追问：-g 会影响发布版性能吗？（调试信息在独立段，不参与执行，不影响运行速度）

  评分要点：

  • core dump 机制与 gdb 回放
  • ulimit 配置
  • 无 core 时的降级方案
• 段错误（SIGSEGV）的定位思路是什么？高频C/C++ · medium

  要点：复现 → gdb run 停在崩溃点 → bt 从栈顶往下找第一帧自己的代码 → 检查指针（NULL/野指针/越界）与数组下标。

  段错误 = 访问了不该访问的内存。标准流程：① 在 gdb 里 run 复现，崩溃时 gdb 自动暂停并显示 SIGSEGV 与行号；② bt 看调用栈——栈顶几帧可能是库函数，从栈顶往下找第一帧"自己写的函数" 才是问题入口；③ 在那里 print 相关指针与下标：NULL？已 free？越界？未初始化？ 常见根因：解引用 NULL/野指针、数组越界写坏返回地址、栈溢出（大局部数组）、double free。 本章 ex1/ex2 就是这套流程的最小演示（store 里对 NULL 解引用，bt 精确到行）。

  追问：

  • 追问：为什么数组越界有时不是立刻崩溃？（写坏相邻内存，可能到函数返回时才炸）

  评分要点：

  • 复现与 bt 定位流程
  • 栈顶找自己代码
  • 常见根因归类
• 调试版和发布版编译选项有什么不同？-O2 会给调试带来什么麻烦？C/C++ · medium

  要点：调试用 -O0 -g（不优化+调试信息）；发布用 -O2（深度优化）。-O2 会导致断点行号漂移、变量显示 <optimized out>，单步顺序与源码不一致。

  优化会重排/合并/消除代码：行号不再与源码一一对应（断点打在循环内却停在函数末尾，本章 ex3 实测），中间变量被常量折叠后连内存位置都没有（print 显示 <optimized out>）。 工程实践：开发构建 -O0 -g 或 -Og（为调试友好的轻优化，GCC 提供）；发布构建 -O2 （必要排查时也带 -g，调试信息不影响运行性能）。回答要点：选项组合 + 两个具体症状 + 对策。

  追问：

  • 追问：-Og 是什么？（GCC 专为调试设计的优化级别，性能损失小、变量基本可看）

  评分要点：

  • -O0 -g vs -O2 组合
  • 行号漂移与 optimized out 两个症状
  • 发布版带 -g 的工程常识

内容来源映射