OpenAI 靠「流行病学分析」抓虫：查出硬件故障与潜伏 18 年的开源 Bug

当线上的 C++ 服务突然崩溃，而且每次崩的方式都透着一种说不出的诡异，最头疼的往往不是代码写错了，而是所有的常规线索都在说谎。

OpenAI 最近在内部的 Rockset 服务上就遇到了这种见鬼的事。Rockset 是 OpenAI 在 2024 年收购的云原生数据系统，全是用 C++ 写的，专门负责 ChatGPT 联网搜索、插件调用以及工作区知识库的流式同步。前段时间，这个系统开始偶尔崩溃，报错看起来极其离谱：函数明明正常执行完了，返回时却跳到了一个根本不存在的代码地址。有时候栈里的返回地址直接变成了空指针 NULL，有时候栈指针寄存器偏了整整 8 个字节。

懂底层的人都知道，现代编译器在普通函数里根本不可能写出这种错。OpenAI 团队一开始像医生看病一样，抓着单个崩溃现场反复研究，甚至查到了 Linux 内核与信号机制，但每一个假设都被自己手头的证据推翻了。

让 ChatGPT 给一整年的崩溃切片

卡住之后，团队决定换个思路，从单案诊断转向流行病学调查。既然盯住一个患者看不出名堂，不如把过去一年所有崩溃样本拉出来，做群体层面的统计分析。

但这事人力根本看不过来。他们让 ChatGPT 写了一个自动化分析脚本，直接调取存储在 Azure 上的核心转储文件，提取出崩溃瞬间的寄存器状态和调用栈，再结合日志自动分类。这个脚本把一整年积累的生产环境转储全部跑了一遍，立刻将原本混在一起的崩溃切成了两个截然不同的群体。

数据一分开，真相就清晰了。看似同一种幽灵崩溃，背后其实藏着两个毫无关联的真凶，只是碰巧撞到了一块。

算错数的 CPU 与潜伏 18 年的开源老虫

第一群崩溃被精准锁定在了一台具体的 Azure 物理宿主机上。那台机器的 CPU 出现了极其罕见的静默硬件算术损坏，连最基础的数字计算都会算错，自然会把栈指针算偏。

另一群更广泛的崩溃，则把矛头指向了广泛使用的基础开源库 GNU libunwind。团队发现，那里面藏着一个存在了整整 18 年的竞态条件漏洞。因为 Rockset 为了精确统计高并发任务的 CPU 开销，每隔几毫秒就会触发一次信号，高频的信号投递碰巧把这个陈年老虫彻底激活了。目前这个漏洞已经被修复并打了补丁。

为什么重要

这起排查对普通用户的直接价值在于，它排除了 ChatGPT 搜索与知识库插件在底层的大规模暗病，检索响应的稳定性会有实打实的提升。对于每天和分布式系统、C++ 打交道的工程师来说，这也是一个非常值得参考的现实样本。

我们认为，OpenAI 这次最聪明的地方不是底层逆向技术有多强，而是排查范式的切换。很多团队在遇到偶发性内存越界或系统崩溃时，往往容易陷入抓着单个堆栈死磕的盲区，最后归咎于玄学。用大模型快速搓出专用脚本，把海量二进制转储变成结构化数据集，用流行病学的统计聚类来破案，这种打法成本极低，却把排查效率拉高了几个数量级。

但这件事也暴露了基础设施层隐秘的脆弱性。大模型底座越来越依赖高性能的 C++ 数据引擎，而在高并发与极端调度压力下，几十年前写下的底层开源库、乃至云厂商物理芯片的一丁点硬件故障，都会被成倍放大。随着 AI 系统对实时上下文检索的需求越来越重，未来这种软硬件交界处的暗坑只会更多，光靠事后抢救不够，全链路的异常监控和自动化归因迟早要变成标配。