AI热榜 OpenAI 的工程师们花了数周时间，试图解释 Rockset 中那些神秘的崩溃问题。
Rockset 是一款 C++ 数据基础设施服务，为 ChatGPT 的搜索和数据插件提供支持。
函数似乎会返回错误的内存地址，栈指针在执行过程中似乎会偏移 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，从而彻底消除了这个时间窗口。
🔗 原始来源
如果你要核对细节，可以再看原文： InfoQ AI原文链接