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

OpenAI 工程师曾耗费数周时间，试图定位 Rockset 中一系列难以捉摸的崩溃现象。Rockset 是一款基于 C++ 构建的数据基础设施服务，为 ChatGPT 的搜索与数据插件提供底层支撑。问题表现为函数返回异常内存地址，执行过程中栈指针（%rsp）无故偏移 8 字节。团队提出的每一种潜在成因，均被后续证据逐一推翻——这个 Bug 看似逻辑上无法成立。

起初他们以为面对的是单一缺陷，最终却揭示出两个完全独立、仅因时间重叠而被同时捕获的深层问题。这一关键转折并非源于对某次崩溃的精细逆向分析，而是源于他们所称的“流行病学式调试”：搭建一套自动化分析流水线，批量解析过去一年中所有生产环境生成的核心转储（core dumps），从全局模式中识别共性，而非拘泥于单点案例的因果推演。

团队借助 ChatGPT 辅助编写脚本，自动拉取每个核心文件的头部数据，提取寄存器快照，过滤已知误报，并将每次崩溃归类为“返回空指针”、“栈对齐异常”等明确类型。该脚本被并行部署于全年 Rockset 核心转储数据集之上。很快，统计规律浮出水面：表面症状高度相似的崩溃事件，实则对应两组截然不同的行为特征。

其中一类由栈对齐异常引发的崩溃，全部集中出现在某个 Azure 区域，具有清晰的起始时间点，且从未在长期稳定运行的节点上复现。进一步排查确认，问题根源是一台物理服务器——其 CPU 在未触发任何硬件告警（如温度超标或机器检查异常）的前提下，持续输出错误的计算结果。该主机下线后，此类崩溃彻底消失。

剔除硬件层面的干扰后，另一类以“返回空指针”为表征的崩溃变得清晰可控。此前，团队曾排除 C++ 异常展开机制作为诱因，理由是部分崩溃发生在明确禁用异常的代码路径中。但这些“反例”全部来自前述存在硬件故障的集群。一旦移除这批噪声数据，剩余所有崩溃均严格发生于异常展开流程之中。

根本症结在于 GNU libunwind 中已潜伏 18 年之久的 _Ux86_64_setcontext 函数内的一处竞争条件。在 C++ 异常展开期间，libunwind 会在栈上动态构造一个 ucontext_t 结构体，填入所需寄存器状态，随后调用 _Ux86_64_setcontext 将控制权交予清理函数。问题在于：该函数在尚未完成从旧结构体中读取指令指针（%rip）之前，就先行更新了栈指针（%rsp）指向新栈帧。一旦 %rsp 变更，原结构体即脱离活动栈范围，不再受内核红区（red zone）保护。若此时恰好有信号（如 SIGUSR2）介入，内核将在该结构体上方压入信号帧，覆盖其内存空间，导致 %rip 被破坏，函数跳转至 NULL 或非法地址。

该竞争窗口仅宽一条指令，按现代处理器频率估算约为 100 皮秒。在绝大多数程序中，此条件几乎不可能被触发。然而 OpenAI 的 Rockset 使用 timer_create 接口，以毫秒级粒度高频发送 SIGUSR2 信号，用于轻量级查询级资源计量——这种远超常规应用的信号密度，将理论上的竞态风险转化为了现实中的高频崩溃。

团队已向 GNU libunwind 提交了修复补丁及可复现的最小化测试用例，并经验证确认：其他主流展开器（如 libgcc）不受此问题影响。修复方案通过调整指令顺序，确保在更新 %rsp 前完成 %rip 的读取操作，从而彻底消除该时间窗口。

他们对此经验的总结尤为精辟，值得全文引用：

最关键的一步，既非对汇编代码的精妙解读，也非对底层细节的极致钻研，而是构建一个高质量、全覆盖的数据集。若缺失这一基础，我们便会不自觉地将两类本质迥异的现象混为一谈，并徒劳地试图用单一逻辑去解释全部混乱。而一旦拥有了准确、完整、带标签的全量故障数据，问题的真实结构便自然浮现。

如果你的团队正深陷于难以复现或解释的生产环境崩溃排查中，请先审视：是否无意间将多个独立缺陷当作同一问题处理？那些看似与所有既有假设相悖的症状，未必自相矛盾；它们很可能分别契合两个不同模型，只是你尚未将其区分清楚。最快洞察问题本质的方式，往往不是把单个案例挖得更深，而是获取一份囊括全部故障实例、经过清洗与标注的完整数据集。

这篇深度技术博文附有详尽的栈内存布局图解、含缺陷的汇编指令片段，以及直观呈现两类故障分布趋势的崩溃率可视化图表。

原文链接：https://www.php.cn/link/c86d9cab5741a9ce01b0403217f274ca

本文来自微信公众号“AI前线”，作者：Steef-Jan Wiggers；译者：平川 ，36氪经授权发布。