OpenAI 的工程师们对着Rockset的崩溃日志，头疼了整整几周。Rockset是ChatGPT搜索和数据插件的底层C++数据基础设施。函数返回的内存地址像是从错误的地方拿来的，栈指针在执行过程中总是莫名其妙地偏移了8个字节。团队每提出一个假设，都立刻被已有的证据推翻。这个Bug，理论上根本不应该存在。

他们原本以为自己面对的是一个Bug，结果却发现是两个互不相干的Bug，只是恰好凑巧在同一时间被暴露出来。这个突破性发现，并非来自对单个崩溃事件的深挖，而是源于他们转向了一种全新的思路——他们称之为“流行病学调试”：构建一条自动化的分析管道，把过去一年生产环境中所有核心转储文件都处理一遍，然后从整体上寻找规律，而不是针对单个案例做推断。

团队让ChatGPT写了个脚本，用来下载每个核心文件的开头部分，提取寄存器数据，过滤掉已知的误报，然后给每次崩溃贴上“返回空指针”、“栈对齐错误”或者其他类型的标签。这个脚本被并行地应用到过去一年里所有Rockset的核心转储文件上。很快，他们发现了一些相关性。原本看起来症状相似的问题，实际上对应着两组特征完全不同的崩溃事件。

那些因栈对齐错误导致的崩溃，都来自同一个Azure区域，有明确的起始日期，而且从未出现在长期运行的节点上。团队顺着线索追踪，发现罪魁祸首是一台物理主机，它的CPU在悄无声息地产生错误的结果。CPU没有过热，也没有抛出机器检查异常，只是默默地做错了数学运算。把这台主机从服务中移除后，所有因栈对齐错误导致的崩溃就彻底消失了。

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

问题的根源，出在GNU libunwind的`_Ux86_64_setcontext`函数里，一个存在了18年的竞争条件。在C++异常展开过程中，libunwind会在栈上合成一个`ucontext_t`结构体，填充好所需的寄存器状态，然后调用`_Ux86_64_setcontext`来把控制权转交给清理处理程序。问题就在这里：`_Ux86_64_setcontext`在从旧的结构体中读取指令指针（%rip）之前，先把栈指针（%rsp）更新到了新的栈帧上。一旦%rsp变了，这个结构体就不再属于活动栈的一部分，也不再受内核红区的保护。如果信号恰好在%rsp更新与%rip读取之间的这个时间窗口内到达，内核就会在这个结构体之上构建自己的信号帧，指令指针被覆盖，函数就会跳转到NULL或垃圾地址。

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

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

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

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

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

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