#基础设施

OpenAI 工程师用『流行病学方法』调试 Rockset 18 年老 bug:不要医生式单 case,要先建高质量数据集

OpenAI 工程团队用流行病学方法调试 Rockset(2024 年被收购)内部诡异崩溃。症状:正常 C++ 函数返回到非法地址,有时 NULL、有时 %rsp 偏移 8 字节。最初假设单一 bug,实际是两个独立问题:(1) 单台 Azure 物理机 CPU 硬件故障导致 %rsp 错位崩溃——所有相关崩溃集中在单一区域、有明确起点、新节点,从该机型下架后消失;(2) GNU libunwind 一个存在 18 年的竞态条件——_Ux86_64_setcontext 在更新 %rsp 后读取 RIP 前存在约 100 皮秒窗口,若此时 SIGUSR2 到达会破坏 ucontext_t 结构,使 RIP 变成 NULL。OpenAI 频繁用 SIGUSR2 做 CPU 计时、且异常作为 ingest 背压机制每秒可抛 10^4 次,导致单个高负载主机平均 10^4 秒(几小时)就崩一次。今年早些时候在 SIGUSR2 处理器中加入 timer_getoverrun 调用扩大栈使用,触发了原本隐蔽的 bug。缓解方案:切换到 libgcc unwinder 并向上游提交 reproducer 与 fix。核心经验:不要靠医生式的单 case 调试,要先建立高质量的全人群数据集。

这是一篇『系统工程师反思』式的工程故事,真正的价值不在 bug 本身而在方法论——OpenAI 把 SIGUSR2 处理器加 timer_getoverrun 触发了原本隐蔽的 18 年 bug,而单 case 调试永远找不到这种『上层改一下就让底层崩』的根因。把流行病学『先全人群数据再定位』搬到调试流程,是值得每个 infra 团队借鉴的方法论。同时也提醒:GNU libunwind 这个被广泛依赖的基础设施仍存在竞态窗口,且 OpenAI 的『异常做背压』实践本身也在把这条路径推到极限——值得 vLLM / SGLang / llama.cpp 等高性能推理框架跟进上游修复。