一句话看懂：OpenAI 工程师在调试 Rockset 数据库生产环境崩溃时，采用“流行病学调试”方法分析一年内的核心转储文件，发现崩溃由两个独立Bug引起——一个是受损硬件导致的计算错误，另一个是 GNU libunwind 库中存在 18 年的竞争条件漏洞，该漏洞在特定高频信号场景下被触发。
事件核心：发生了什么
OpenAI 的 Rockset 服务（为 ChatGPT 搜索和数据插件提供支持的C++基础设施）持续出现神秘崩溃：函数返回错误内存地址，栈指针偏移8字节。团队原本试图解释单一Bug，但发现症状背后是两类不同问题：一类崩溃来自同一Azure区域的某台物理主机，其CPU悄无声息地产生错误数学运算结果；另一类则在剔除硬件问题后，全部指向C++异常展开过程。进一步追踪发现，后一类崩溃根因是 GNU libunwind 的 _Ux86_64_setcontext 函数中存在一个存在 18 年的竞争条件：当更新栈指针与读取指令指针的时序窗口（约100皮秒）恰好被信号中断时，指令指针被破坏，导致跳转到空或垃圾地址。OpenAI 的 Rockset 使用 timer_create 每几毫秒发送一次 SIGUSR2 信号用于按查询记账，极高频的信号发送将理论概率转化为了实际崩溃。该团队已向 GNU libunwind 提交修复方案，通过重新排序指令消除竞争窗口。
为什么重要
这一案例展示了AI基础设施调试中“数据质量优于直觉推断”的核心方法论。OpenAI 构建管道自动分析过去一年中所有核心转储文件（并行运行在数千个文件上），用标签化分类取代对单个案例的深度推理，才避免了将两类崩溃混为一谈的误区。这种“流行病学调试”思路对运行大规模分布式AI服务的团队有直接借鉴意义——当崩溃日志看起来自相矛盾时，往往是多个独立Bug在同时作用。此外，该漏洞在GNU libunwind中存在长达18年未被发现，说明基础库的潜在缺陷需要特殊生产环境（高频信号+长时间运行）才能暴露，对AI基础设施的稳定性和调试方法提出了更高要求。
对用户/开发者/创作者的影响
对AI基础设施开发者而言，应检查自己的C++服务是否使用 libunwind 进行异常展开，以及是否使用高频定时信号；如果两者同时存在，建议关注上游修复或临时禁用触发器。对使用 ChatGPT 搜索和数据插件的普通用户来说，修复后相关功能的稳定性会间接提升。对从事生产环境调试的团队，该案例提供了可复用的方法论：不要仅依赖对单个崩溃案例深度分析，而应构建可批量处理、自动标记、统计归因的全量数据管道，尤其在涉及分布式系统和硬件异构性时。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
首先，GNU libunwind 官方是否加速合入该修复补丁，以及是否会回溯到长期支持版本。其次，其他使用类似高频信号方案的C++服务（如实时分析、审计计费类系统）是否会涌现出相同漏洞的汇报。最后，OpenAI 是否将“流行病学调试”工具和方法论开源，以降低行业排查类似复杂崩溃的门槛。
来源：InfoQ CN
