Core Dump 流行病学：修复一个 18 年的 bug

有时候，最棘手的 Bug 不是报错信息最扎眼的那种，而是那些让系统间歇性抽风、日志干净得像被洗过一样的幽灵故障。OpenAI 的工程师最近就摊上了这么一件事：他们的基础设施偶尔会毫无征兆地崩溃，频率不高，但足够让人抓狂。为了揪出元凶，他们干起了类似“法医流行病学”的活儿——大规模分析 Core Dump。

Core Dump 里的犯罪现场

所谓 Core Dump，就是程序崩溃时内存的快照。通常没人会去翻它，除非你像 OpenAI 的 SRE 团队一样，面对一个持续多年、来历不明的崩溃模式。他们每天收集数千份 Core Dump，像病理学家一样寻找共性。这一找就是好几个月。

最终，他们锁定了两种截然不同的病因。一种来自内存硬件错误：某个 CPU 的缓存偶尔会吐出错误数据。另一种则是一个软件 Bug，在 Linux 内核的某个边缘路径里已经藏了 18 年，从 2006 年 Linux 2.6 时代就存在了。两个问题同时出现时，系统才会崩溃——就像枪里有两颗子弹，只有同时上膛才会走火。

为什么花了 18 年才被发现？

这个软件 Bug 的触发条件极其苛刻。它涉及内核的 SLUB 内存分配器在特定竞态条件下返回错误指针，而硬件错误恰好会在同一时刻把错误指针变成可执行的畸形代码。单独看，每个问题都不致命；凑在一起，就是灾难。大部分时候硬件错误被 ECC 纠错掩盖了，只有软硬件共同出错时才会露出马脚。

OpenAI 的团队用了一个巧妙的办法来确认关联：他们写了一个内核模块，主动在特定内存地址注入错误，发现只有当内核 Bug 也被触发时，系统才会崩溃。这种“协同故障”模式在分布式系统中极为罕见，但一旦发生，诊断难度呈指数级上升。

一些关键发现来自对 Core Dump 中特定寄存器的分析——比如某个 CPU 的 MCA（Machine Check Architecture）记录显示缓存奇偶校验错误，而另一个内核线程的调用栈正好指向了 SLUB 分配器的那个古老 bug。

修复之后，能学到什么？

修复方案本身并不复杂：硬件层面通过微码更新禁用有问题的缓存预取逻辑，软件层面给内核的那段分配代码加了一个内存屏障。真正有价值的是调试过程本身——大规模 Core Dump 分析从一种被动的事后检查，变成了主动的流行病学调查。

对运维工程师而言，这个案例有几个值得记住的点：

• 不要只关注日志中的显式错误，Core Dump 里的每一比特都可能藏着线索。
• 当多个软硬件组件同时表现出“轻微异常”时，要考虑它们之间是否存在耦合故障。
• 自动化分析工具在处理海量 Core Dump 时不可或缺，但最终判断仍需要工程师对内核机制有深入理解。

OpenAI 并没有止步于修复这个单一 Bug。他们把整套分析框架沉淀下来，用于持续监控生产环境中的类似模式。用他们自己的话说：“我们不再是等崩溃发生再排查，而是主动扫描所有 Core Dump，寻找那些尚未引爆的定时炸弹。”

这大概是 18 年 bug 带给我们的最好启示：有些故障注定只能被耐心、数据和一点运气发现。但做好准备的人，运气往往更好。