【OPENAI】从群体核心转储排查旧故障

OpenAI 团队通过对大量核心转储进行“流行病学式”分析，定位并修复了两个同时出现但无关的故障：一台 Azure 主机的沉默硬件错误和 GNU libunwind 中一个存在 18 年的竞态条件。本文介绍了他们如何构建高质量故障数据集、分离假设并最终找到根因。

背景

• 问题发生在 Rockset（OpenAI 收购的实时搜索/分析系统）的 C++ 执行层，表现为函数返回到无效地址或返回地址为 NULL，导致内核终止程序。
• 初期仅靠逐个分析几个 core dump 很难建立可靠结论，日志也因栈损坏而难以分类。

诊断方法：把调试当成流行病学

• 团队改变策略：收集并分析整个人群（所有崩溃）的核心转储，构建可供统计与归类的高质量数据集。
• 利用 frame pointer 与 x86_64 的 128 字节 red zone 保留信息，恢复出错前的栈与寄存器状态，帮助识别不同故障模式。

发现的两个独立缺陷

• Bug A：单台 Azure 主机出现的沉默硬件错误（CPU 计算错误），导致个别崩溃表现为栈或返回地址异常。
• Bug B：GNU libunwind 中一个存在约 18 年的竞态条件，会在稀有窗口内导致栈展开/返回行为被错误处理，从而把一些崩溃伪装成普通返回错误。

为什么两个问题同时出现

• 两个缺陷互相混淆了症状：硬件错误导致的少量异常与 libunwind 的长期竞态叠加，令初始分析误以为只有单一原因。
• 通过群体级别的诊断与数据清洗，团队能够把不同模式分离并分别验证其根因。

经验与启示

• 构建可分析的、覆盖全部故障样本的数据集对于排查稀发/复杂错误至关重要。
• 在系统级崩溃调查中，要警惕硬件故障与老旧第三方库的隐藏问题，同时避免过早收敛到单一假设。
• 利用 ABI 细节（如 red zone 和帧指针）能提供关键线索，弥补日志与常规方法的不足。

把调试视为群体问题而非孤立事件，能揭示被单次样本掩盖的真因。

原文链接