OpenAI 借助群体分析法修复存续18年的 CPU 崩溃 bug
本文展示了如何通过大规模崩溃数据分析，同时定位硬件错误和古老库缺陷，对构建高可靠分布式系统有重要参考。
OpenAI 在 ChatGPT 数据基础设施中发现两种看似不可能的崩溃：一是单台 Azure 主机的 CPU 硬件损坏导致计算错误，二是 GNU libunwind 库中存在一个 18 年历史的竞态条件。工程师通过流行病学思路，收集全量崩溃数据并分析，最终定位并修复了这两个独立 bug。
正文摘录
2026年6月30日 [Engineering](https://openai.com/news/engineering/) Core dump 流行病学：修复一个 18 年的 Bug 利用群体层面分析来调试数据基础设施中棘手的崩溃问题。 Loading… 分享 OpenAI 的模型和 Agent 越来越依赖可扩展的数据基础设施，以便在推理时（即模型思考你的问题的时候）搜索相关数据。其中一些服务是用 C++ 编写的，C++ 对系统的底层控制使我们能够最大化性能并最小化内存使用。随着规模扩大，这些效率优势很重要，但 C++ 缺乏内存安全性意味着，写入错误或不存在的内存地址的 Bug 可能会导致崩溃。 几个月前，我们在 Rockset 服务内部观察到一些崩溃。Rockset 是我们 ChatGPT 数据基础设施中的一个定制部分，对许多数据插件和搜索对话历史至关重要。在每一次这样的崩溃中，一个正常的 C++ 函数似乎完成了执行，然后返回到了一个虚假的地址，导致内核停止了程序，因为指令指针不再指向代码。有时栈帧中保存的返回地址槽是 NULL。有时栈指针 CPU 寄存器本身似乎偏移了 8 字节，就好像 %rsp 在正常执行过程中被错误地减少了。在两种情况下，崩溃都发生在函数返回时。 这些不是应用程序代码的正常故障模式。一个恰好只覆盖了保存的返回地址的随机写入是可能的，但极其罕见。一个没有涉及内联汇编、setcontext 或 longjmp（我们都没有使用）的使 %rsp 偏移 8 的 Bug 则更奇怪，因为编译后的代码只在函数序言和尾声部分直接调整该寄存器。我们（或 ChatGPT）能想到的每一个假设都有强有力的证据反对它，所以这个 Bug 似乎不可能存在。 我们最初认为的一个问题，最终被证明是两个不相关的 Bug，巧合地在同一时间被发现。