4.3 寻址错位排错实录：三个 Bug 复盘

4.3 寻址错位排错实录：三个 Bug 复盘

本节摘要：地址类错误在源码层面往往"时隐时现"，到汇编层面却证据齐全。本节完整复盘三个真实案例：栈失衡导致的连环返回错乱、缺失符号扩展导致的负下标奇幻漂流、栈未对齐导致的 SSE 指令崩溃——每个案例都按背景、现场、排查、解读、修复、变式六步走完，最后汇总成一张可复用的排错清单。读完你处理段错误与数值错乱的思路会从"猜"升级为"查"。

三个现场，三种错法

选案例有三个标准：真实（都来自实际项目的精简重演）、错法互不重叠（分别对应栈协议、寻址扩展、对齐要求）、排查手段各有代表性（backtrace 分析、寄存器对账、崩溃指令定位）。三个案例走完，你会发现所有地址类错误的排查骨架是同一套：先看崩溃点，再对寄存器快照，最后让内存内容开口作证。

图 4-3：三个案例的错位现场示意

案例一：压两个弹一个——栈失衡连环劫

背景：项目里一个手写的快速哈希函数给 C 主程序调用，压栈保存 rbx 与 r12 两个被调方需保存的寄存器，循环里做混洗，收尾恢复寄存器返回。功能测试全过，集成测试一崩。

现场：程序崩在一个"从未被这行代码调用"的字符串函数里，backtrace 显示的调用链完全不合逻辑——上层函数名对不上任何真实调用路径。

排查：GDB 载入崩溃转储，第一步看崩溃点与栈指针：

(gdb) bt
#0  0x00007f3a2b91d0f3 in strcasecmp_avx ()   ← 从没调用过它
#1  0x0000000000405122 in ?? ()
(gdb) info registers rsp
rsp  0x7ffd3a2c7f08
(gdb) x/4gx $rsp
0x7ffd3a2c7f08: 0x00000000004051a3  0x00007ffd3a2c7f18
0x7ffd3a2c7f18: 0x0000000000000000  0x0000000000401200
​

崩溃点在陌生地址、backtrace 第二帧已是问号——教科书级的栈失衡信号。检查源码，压栈两条、弹栈一条：循环中途为了复用 r12 做临时计算，把收尾的 pop rbx 误删了。于是 ret 弹出的不是返回地址而是 rbx 的旧值，CPU"返回"到了一个把数据当地码的地址；同时 rsp 恒偏 8 字节，caller 的整条返回链从此错位，backtrace 自然面目全非。

解读与修复：栈失衡的杀伤机制是"一处错、处处错"——偏移会沿调用链向上传染。修复只需补回那条 pop rbx，但验证要完整：单步到 ret 处执行 x/1gx $rsp 确认栈顶就是预期的返回地址，再放行。变式：这个 bug 有个更阴的形态——push/pop 数量配平但顺序错（pop rbx 与 pop r12 写反），数量对、内容错，寄存器互换后程序不崩但数据错乱，排查时对"配平"的检查必须包括顺序。

案例二：一个负下标的奇幻漂流——缺失的符号扩展

背景：图像处理代码按行列扫描像素，某滤波分支允许"当前行前一列"的下标为 -1，C 层逻辑用有符号 int 表示下标，汇编优化的热路径里这个下标被用于数组寻址。

现场：不崩，但滤波结果出现规律的竖条状错误——每逢下标为负，读到的"像素"是离谱的大数值。

排查：先看热路径的反汇编，下标载入与寻址两步是分开的：

mov  eax, [rbp - 12]        ; 载入 int 下标（32 位）
lea  rbx, [rdi + rax]       ; 直接当 64 位偏移用 ← 问题所在
​

GDB 里下条件断点，让下标为负时停下来对账：

(gdb) break pixel_filter if idx < 0
(gdb) continue
(gdb) p idx
$1 = -1
(gdb) info registers rax
rax 0xffffffff  4294967295
​

水落石出：内存里 -1 的确是四字节的 FF FF FF FF，但 mov eax 载入 32 位后高 32 位被清零（3.1 节那条脾气），rax 变成 0xFFFFFFFF——十进制 4294967295 的巨大正数。后续 lea 用它做偏移，访问远越界的地址：有时落在映射过的区域读到垃圾（表现为数据错乱），有时落在未映射区（表现为段错误）。同一个 bug、两种病症，全看运气。

解读与修复：把载入改成 movsxd（32 位符号扩展到 64 位），负值的高位正确复制符号位，rax 得到 0xFFFFFFFFFFFFFFFF 即真正的 -1。修复一行，验证也一行：断点里重查 rax 应为 0xFFFFFFFFFFFFFFFF。变式：反过来，无符号数需要的是零扩展（movzx）而不是 movsxd——用错方向，小正数会变成巨大负数。判别口诀：源类型有符号用 movsxd，无符号用 movzx，凭"看数值像不像"猜扩展方向是纯赌博。

案例三：调试版岁月静好，发布版当场去世——movaps 的对齐执念

背景：一个含 SIMD 优化的视频滤镜库，调试构建一切正常，改成发布构建（-O2 且手写汇编接手热路径）后，初始化阶段必崩。

现场：崩溃点精确定位在一条 movaps 指令上，报错为通用保护异常（段错误的另一种成因）。

排查：

(gdb) x/1i $pc
=> 0x4028b1 <blend_row+17>:  movaps XMMWORD PTR [rsp], xmm0
(gdb) p $rsp
$2 = (void *) 0x7ffd3a2c7f68
(gdb) p $rsp % 16
$3 = 8
​

movaps（对齐版整数搬送）硬性要求地址 16 字节对齐，而此刻 rsp 对 16 取模余 8——栈没对齐。为什么调试版没事？ABI 规定 call 指令执行时 rsp 必须是 16 的倍数（这要求源于把返回地址压栈后，函数体内 rsp 恰好还能保证 SSE 载入对齐）；调试构建里这条手写函数没被内联、调用点恰好满足要求；发布构建里编译器重排了调用点，进函数时 rsp 落在了 8 的倍数上——同一个函数、两种命运。

解读与修复：手写汇编进场时主动对齐：开场 push rbp 后若 rsp 仍不对齐，补一条 sub rsp, 8，或干脆用 and rsp, -16 强制归零低四位（配合保存原 rsp 以便退出恢复）。修复后用 p 命令验证 rsp 对 16 取模为零，movaps 稳定通过。变式：除了栈对齐，全局数据也有同类要求——align 16 声明过的数据被 movdqa 访问才合法，2.2 节模板里的 align 伪指令正是为这个场合预留的。

排错方法论：一张可复用的现场清单

三个案例合并提炼，地址类错误的排查骨架固定为五步：定位崩溃指令（x/1i）→ 检查寄存器与期望值对账（info registers）→ 检查栈内容与配平（x 命令加数 push/pop）→ 检查对齐（对 16 取模）→ 修复后带断点回归验证。清单的价值在于顺序：崩溃指令告诉你"哪条动作错了"，寄存器对账告诉你"数据在哪一步开始不对"，栈与对齐检查覆盖余下两类根因。绝大多数段错误走不完五步就现形——剩下的疑难杂症，6.2 节的调试器进阶技巧接手。

⚠️ 常见坑：见到段错误就怀疑指针没初始化。三个案例没有一个与"忘了初始化"有关——失衡、扩展、对齐全是指针值正确的计算环节出错。先查计算，再怀疑来源，这是老手与新手排错效率差异最大的一处。

💡 关键直觉：地址类 bug 的汇编层表现永远"证据充分"——寄存器快照、栈内容、崩溃指令三样证据齐备，拼起来就是完整案情。源码层"诡异"只是因为证据在高层被抽象掉了；下到汇编层，破案靠的是读证词，不是灵感。

本节要点回顾

• 栈失衡的病症：崩在陌生地址、backtrace 错乱、rsp 恒偏固定字节；检查 push/pop 数量与顺序双重配平。
• 符号扩展的方向：有符号用 movsxd、无符号用 movzx；mov 载入 32 位会清高 32 位，负数瞬间变巨大正数。
• 对齐是硬性条款：movaps 与 movdqa 要求 16 字节对齐，ABI 的 16 字节栈对齐约定是背景约束，手写进场代码要主动维持。
• 五步排查骨架：崩溃指令、寄存器对账、栈检查、对齐检查、回归验证，顺序固定可复用。

破案能力到手，视角该转一转了。下一章让编译器写汇编、我们当审稿人：那些手写时踩过的坑，编译器是如何绕开的。