OpenAI 如何用流行病学调试发现两个隐藏的崩溃根源

一场看似不可能的崩溃 OpenAI 工程师曾连续数周陷入困境：Rockset——一款为 ChatGPT 搜索与数据插件提供底层支持的 C++ 数据基础设施服务——频繁发生神秘崩溃。现象异常诡异：函数返回错误内存地址，栈指针（%rsp）在执行中无故偏移 8 字节。所有常规假设都被逐一证伪，问题仿佛违反底层硬件与编译器的基本约束，根本‘不可能存在’。 从单点排查转向全局模式识别 转折点并非来自更深入的汇编级追踪，而是一次方法论转变：团队放弃逐个分析崩溃现场，转而启动‘流行病学调试’——将过去一年生产环境中全部核心转储（core dumps）纳入统一分析管道，不预设因果，只寻找统计规律。 他们让 ChatGPT 协助编写自动化脚本：批量下载每个 core dump 的头部数据，提取关键寄存器状态，过滤已知误报，并按崩溃类型打标（如‘返回空指针’‘栈对齐错误’）。当脚本并行处理数千份历史记录后，一个清晰分界浮现：表面相似的崩溃，实则属于两类完全独立的故障模式。 第一类崩溃：沉默的硬件失效 所有标记为‘栈对齐错误’的崩溃，高度集中于同一 Azure 区域，有明确的起始时间点，且仅出现在新部署节点上——长期运行的实例从未复现。进一步定位发现，问题源自一台物理主机：其 CPU 在未触发任何硬件异常（如 MCE）、未出现过热迹象的情况下，持续产出错误的算术结果。这不是偶发毛刺，而是稳定、隐蔽的逻辑错误。下线该主机后，此类崩溃彻底消失。 第二类崩溃：被掩盖的软件竞态 剔除硬件问题后，剩余‘返回空指针’类崩溃突然变得可解释。此前团队曾排除 C++ 异常展开路径，理由是部分崩溃发生在‘未启用异常’的代码分支。但这些‘反例’全部来自前述故障主机集群——硬件错误污染了判断。一旦剥离干扰，所有剩余崩溃均严格落在异常展开过程中。 根因最终锁定在 GNU libunwind 的 _Ux86_64_setcontext 函数：一个存在 18 年的竞争条件。该函数在异常清理时需在栈上构造 ucontext_t 结构体，并原子化切换控制流。但其实现中，先更新 %rsp 指向新栈帧，再读取 %rip；若在此间隔（仅一条指令，约 100 皮秒）内收到信号，内核将在已被移出活跃栈的结构体上方压入信号帧，导致 %rip 被覆盖为无效值，函数跳转至 NULL 或随机地址。 高频信号放大了理论风险 这一竞态在绝大多数程序中永不触发。但在 Rockset 中，为实现细粒度查询计费，系统通过 timer_create 每几毫秒 CPU 时间就发送一次 SIGUSR2。这种远超常规的信号频率，将百万分之一的概率转化成了可观测的、高频的生产事故。 修复与启示 团队向 GNU libunwind 提交了修复补丁：重排指令顺序，确保 %rip 读取完成后再更新 %rsp。同时提供最小可复现示例，并验证 libgcc 等其他展开器不受影响。 他们总结的核心经验直击本质： ‘最重要的步骤并非巧妙地解读汇编代码，也不是对细节的深入了解，而是构建一个高质量的数据集。如果没有这个数据集，我们就会把两种截然不同的现象混为一谈，并试图通过推理来理清这种混乱。一旦获得了准确且完整的全量数据，问题的结构便显而易见了。’ 当你的服务遭遇‘无法解释’的崩溃，请先问：是否正用单一模型解释多个独立故障？那些互相矛盾的线索，可能不是逻辑漏洞，而是分类缺失的信号。真正加速破局的，往往不是更深的单点挖掘，而是更广的、带标签的全量故障图谱。