调试与验证：把猜测变成证据

调试首先是缩小问题，而不是同时打开更多工具。一个好问题应该形如：“在第三次 free 之后，后继块的 prev 不再指向物理前驱”，而不是“分配器似乎有 bug”。明确第一处违背的不变量，工具才知道该观察什么。

建立最小可重现输入

先固定编译命令、输入文件和随机种子，再删除不影响错误的操作。缓存错误可缩为几条 trace；分配器错误可缩为 alloc A → alloc B → free A → free B；进程竞态则需要保留事件顺序与同步条件。不要只保存屏幕上的某一次输出。

仓库 verify.sh 使用手算 oracle 验证缓存结果，使用固定种子产生分配器请求，再逐字节验证所有活跃载荷。固定随机不等于穷尽所有状态，但能稳定复现观察到的错误。修改实现后先跑原反例，再运行相应回归，不要用“换个输入不报错了”替代修复。

编译警告与 sanitizer 的分工

make -C labs/csapp clean
make -C labs/csapp test
make -C labs/csapp sanitize

默认启用 -Wall -Wextra -Wpedantic -Werror，让可疑类型转换、格式串和未使用变量等问题尽早暴露。-g 保留调试信息，不代表关闭优化；为了逐行调试，可清理后使用 CFLAGS='-std=c11 -O0 -g -Wall -Wextra -Wpedantic' 重建。

ASan 擅长捕获许多堆栈越界、释放后使用等错误，UBSan 检测一部分未定义行为。它们都不是正确性的证明。ASan 看不懂自建 arena 的所有内部边界；UBSan 不会自动证明锁协议正确；正常测试通过也可能只是没有触发某个并发调度。ThreadSanitizer 适合另做数据竞争检测，但本仓库没有把它列为已经执行的验证。

GDB 的三种观察层次

在 Linux x86-64 实验环境，先用函数断点定位，再观察 C 变量，最后下到寄存器与字节。

break arena_free
run
bt
print *b
next
step
watch b->capacity
continue

变量 b 只有在作用域内且已初始化后才可可靠观察，优化也可能消除它。若是二进制实验：

break phase_1
disassemble phase_1
info registers
x/8gx $rsp
x/16bx $rdi
x/s $rdi
si
ni

x 的重复数、显示格式和单位分别决定读多少、怎样显示、每项多宽；x/8gx 是按 8 字节单位显示 8 项十六进制数，x/16bx 按字节查看 16 项。x/s 只在地址确实指向可读取的终止字符串时才有你期望的含义。GDB 内存检查手册

macOS 可用 LLDB，但命令并非完全相同。常见对应是 breakpoint set --name arena_free、run、thread backtrace、frame variable、register read、disassemble --name arena_free。先用 help 确认当前工具语法，不要机械粘贴 GDB 输出。

四类故障的最短定位路径

现象	先验证	最有效的下一步
cache 统计多一次 eviction	victim 是否原本有效	对单条访问打印组内所有 tag/valid/stamp
allocator 几百步后崩溃	首次不变量失败在哪一步	每步检查，缩减请求序列，watch 损坏字段
Shell 偶尔永久等待	检查与睡眠是否原子衔接	画信号 block/unblock 与退出时间线
多线程偶发值错误	所有冲突访问是否同一同步协议	列出字段所有读写者，不先增加 sleep

对于分配器，在一段内存上以不同宽度查看很有用：字节视图定位覆盖边界，整数视图读大小字段，指针视图读链表。但显示格式只能帮助解释，不能改变实际布局。先用 sizeof、offsetof 与对齐计算确定结构，而不是从打印出的十六进制随意猜测。

性能实验要能比较

比较两个转置实现时，保持输入尺寸、内容、编译选项、机器和测量方法不变。预热、缓存状态、后台负载和计时粒度会影响结果；报告多次测量及离散程度，而不是只拿最快一次。对缓存模拟器则使用确定 trace，比较 miss 指标，避免把模拟 miss 与实际纳秒混写。

先做正确性验证，再做性能比较。一个少算一半元素的程序往往“更快”，但没有优化价值。改变算法后还要确认数值语义，例如浮点归约顺序变化可能造成舍入结果不同，需要事先定义容许误差与评估方式。

本仓库的实际验证范围

2026-10-04，macOS arm64、Apple clang 21.0.0：六个 C 程序通过普通严格警告构建和 ASan/UBSan 构建；包含缓存精确统计、分配器 4000 步载荷检查、单孩子信号回收、生产消费序列和前台 Shell 命令。完整日志见 labs/csapp/VALIDATION.md。

没有执行官方评分器、Linux ELF 工具演示、原版 Bomb/Attack、完整作业控制或多线程竞争检测。这样标注使学习者知道哪些可以立即重复，哪些需要补齐环境。

自测：为什么 watchpoint 比在崩溃处打印更适合查内存破坏？

崩溃通常是较早错误写入的后果。watchpoint 可以停在字段被改变的时刻，从当前调用栈追到写入来源；它更接近原因。但硬件数量和粒度有限，应先定位到少量可疑字段。

自测：加一条 printf 后竞态消失，说明修复了吗？

没有。I/O 改变调度与时序，可能掩盖错误。需要建立同步关系，保证所有合法调度都遵守关键不变量。

下一章：综合复习。