一句话看懂：OpenAI 工程师在排查 ChatGPT 数据基础设施偶发崩溃时，发现两个极难复现的 bug：一个是 18 年前 GNU libunwind 库中的竞态条件，另一个是 Azure 宿主机的硬件静默损坏。团队采用类似流行病学的人口级数据分析方法，才从数百万次执行中定位出这两个“不可能”的错误。
事件核心：发生了什么
OpenAI 的 C++ 数据基础设施 Rockset（2024 年收购）在服务 ChatGPT 对话搜索和数据插件时，出现异常的段错误崩溃。崩溃表现为函数正常执行后返回到一个非法地址，或者栈指针偏移 8 字节。传统逐个分析核心转储的方法无法定位原因，因为破坏发生在栈上，日志本身已被污染。团队转而收集所有崩溃的元数据，构建完整数据集做统计异常分析——这种方法他们称之为“核心转储流行病学”。最终定位出两个独立但同时触发的 bug：一是某台 Azure 宿主机的 CPU 计算偶尔出错，属于硬件静默数据损坏；二是在 GNU 开源库 libunwind 中潜伏了 18 年的竞态条件，当线程频繁创建和销毁时，栈展开过程会间歇性地读取错误地址。
为什么重要
这个案例揭示了现代 AI 基础设施调试的特殊难度：底层依赖大量 C/C++ 代码追求极致性能，但内存安全缺失导致崩溃难以通过常规测试（包括 ASAN 内存检查）捕捉。OpenAI 的问题排查路径本身也是一种方法论创新——用大规模统计而非单例分析来应对分布式系统中的偶发故障。同时，暴露了云服务供应链中“硬件异常被软件完全掩盖”的风险：硬件错误极其罕见，但一旦发生，会被误判为软件 bug，浪费数月排查时间。修复 libunwind 这种被广泛使用的底库，也将惠及所有依赖该库的 C++ 项目，包括其他 AI 框架和数据库系统。
对用户/开发者/创作者的影响
普通用户不受影响：Rockset 的所有查询实例都有冗余副本，单个崩溃不会导致服务中断。对使用 C++ 做高性能 AI 推理或数据处理的后端开发者而言，这是一个重要的调试参考：当遇到栈被莫名破坏的崩溃时，应考虑硬件验证（ECC 内存校验、CPU 指令验证）和底层库版本（检查 libunwind 是否过旧）。对于使用 OpenAI API 的开发者，此修复不会改变 API 接口或定价，但能提升 ChatGPT 搜索对话历史、获取实时数据时的响应稳定性——崩溃概率降低意味着请求超时或失败的可能性更小。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
首先，OpenAI 是否会将这种“流行病学调试”方法工具化并开源，可能成为 C++ 内存安全调试领域的新实践。其次，硬件静默数据损坏在 Azure 上的发现，是否促使云服务商（尤其是 A100/H100 集群提供方）增强硬件层面的完整性校验，值得企业采购者留意。最后，GNU libunwind 的修复是否会随标准库更新推送到 Linux 发行版，以及是否影响其他依赖该库的 AI 工具链（如 PyTorch 的 JIT 编译链路），是技术生态层面的观察点。
来源：OpenAI News
