OpenAI将崩溃调试视为流行病学研究，修复了存在18之久年的GNU libunwind漏洞

OpenAI 的工程师们曾经被一个诡异的Bug折磨了数周。他们当时正在维护Rockset——一个为ChatGPT搜索和数据插件提供支持的C++数据基础设施服务。问题出在函数会莫名其妙地返回错误的内存地址，栈指针在执行过程中就像被施了魔法一样，凭空偏移了8个字节。团队尝试了各种假设，但每一个都很快被推翻。这个Bug，仿佛根本不存在于现实世界。

结果呢？他们以为是一个Bug，实际上却撞上了两个互不相干的Bug，只是巧合同一时间被触发了。而这一突破，并非来自深入排查某个崩溃案例，而是源于他们转变思路——用他们的话说，这叫“流行病学调试”：构建一条自动化管道，分析过去一年生产环境中的所有核心转储文件，寻找整体规律，而非纠结于单个案例。

于是团队让ChatGPT帮忙写了个脚本，专门用来下载每个核心文件的开头部分、提取寄存器数据、过滤掉已知的误报，然后把每次崩溃标记为“返回空指针”或“栈对齐错误”等类型。接着，他们将这个脚本并行应用于过去一年里Rockset所有的核心转储文件。不出所料，很快发现了相关性：那些症状相似的崩溃，实际上对应着两组特征完全不同的故障。

具体来说，因栈对齐错误导致的崩溃，全部来自同一个Azure区域，有明确的起始日期，而且从未出现在长期运行的节点上。顺藤摸瓜，团队锁定了一台物理主机——它的CPU在悄无声息地产生错误结果。没有过热，没有抛出机器检查异常，只是数学运算默默算错了。将这台主机从服务中移除后，栈对齐错误导致的崩溃就彻底消失了。

剔除硬件问题后，剩下的“返回空指针”崩溃就变得清晰可控了。之前团队曾排除了C++异常展开引发问题的可能性，因为他们找到了反例：有些崩溃发生在未使用异常的代码路径上。但这些反例，全都来自那台有硬件损坏的故障集群。一旦剔除了干扰因素，剩下的所有崩溃就都发生在异常展开过程中了。

根因锁定在GNU libunwind的 _Ux86_64_setcontext 函数中，一个存在了18年的竞争条件。在C++异常展开时，libunwind会在栈上合成一个 ucontext_t 结构体，填充所需的寄存器状态，然后调用 _Ux86_64_setcontext 将控制权转移给清理处理程序。问题在于：_Ux86_64_setcontext 在从旧结构体中读取指令指针的操作尚未完成之前，就把栈指针（%rsp）更新为指向新的栈帧。一旦 %rsp 发生变化，该结构体就不再属于活动栈的一部分，也不再受内核红区的保护。如果信号恰巧在 %rsp 更新与 %rip 读取之间的时间窗口内到达，内核就会在该结构体之上构建其信号帧，指令指针被破坏，函数直接跳转到NULL或垃圾地址。

这个竞争窗口的宽度，只有一条指令。以现代处理器的时钟频率计算，大约相当于100皮秒。在大多数程序里，这种情况根本不会触发。但OpenAI的Rockset用了 timer_create，每隔几毫秒的CPU时间就发送一次 SIGUSR2 信号，目的是实现轻量级的按查询记账。这样一来，信号发送事件的频率远高于传统应用。正是这种高频信号，把理论上可能发生的竞争状态，变成了生产环境中的真实崩溃。

团队最终提交了一个修复方案和自包含的重现示例给GNU libunwind，并验证了其他展开器（如libgcc）不存在这个问题。修复方法很简单：重新排序指令，确保在更新 %rsp 之前先读取 %rip，从而彻底消除这个时间窗口。

团队成员对这一教训的总结，值得全文引用：

最重要的步骤并非巧妙地解读汇编代码，也不是对细节的深入了解，而是构建一个高质量的数据集。如果没有这个数据集，我们就会把两种截然不同的现象混为一谈，并试图通过推理来理清这种混乱。一旦获得了准确且完整的全量数据，问题的结构便显而易见了。

如果你的团队正在排查难以解释的生产环境崩溃问题，不妨先检查一下，是否将多个Bug混为一谈了。那些看似与所有假设都不相符的症状，实际上可能并不矛盾——它们可能分别对应着两个不同的假设，只是你无意中把它们混淆了。洞察问题结构的最快途径，并非对单个案例进行更深入的分析，而是获取涵盖所有故障案例的完整、带标签的数据。

这篇完整的工程技术博文还包含了详细的栈内存示意图、存在漏洞的汇编指令，以及揭示出两种不同类型故障的崩溃率可视化图表。