一个 C++ 函数正常跑完，返回时却跳到了非法地址。

更怪的是，部分 core dump 里返回地址是 NULL；另一些看起来像 CPU 的 %rsp 栈指针偏了 8 字节。

这不是普通业务代码写错的味道。没有 inline assembly，没有 setcontext，没有 longjmp，代码路径也不像会主动把栈玩坏。

OpenAI 最后拆出两个根因：一类来自 Azure 上一台物理宿主机的静默硬件错误；另一类来自 GNU libunwind 里潜伏 18 年的竞态 bug。

我更在意的不是“OpenAI 修了一个底层 bug”。这篇工程博客真正露出的，是 AI 基础设施可靠性正在换打法：从单案调试，转向故障流行病学。

崩溃发生在哪，怪在哪里

Rockset 是 ChatGPT 数据基础设施的一部分，用在插件、会话搜索、实时索引等场景。它让模型在推理时能查到相关数据。

Rockset 的核心执行层使用 C++。性能和控制力都好，代价也硬：一旦踩到运行时、内存或 ABI 边界，崩溃会很难看。

这次问题集中在 Rockset 生产环境的 query leaves。原文也说明，query leaves 有复制机制，单次 segfault 对客户端影响被压低。所以别把它夸成一次用户侧大事故。

但对基础设施团队，这个信号很重。

问题事实影响
发生在哪Rockset 生产环境 query leaves属于 ChatGPT 数据基础设施链路，不是模型本体
现象多怪返回非法地址、返回地址为 NULL、%rsp 偏移 8 字节不像普通应用层 bug
怎么查自动化分析过去一年生产 core dump，打标签、看相关性从看单个病例，变成看全量分布
拆出什么misaligned-stack 与 return-to-null 两类崩溃原本像一个鬼故事，实际是两个根因互相污染证据
用户影响query leaves 有复制机制单次崩溃对客户端影响被最小化，不能夸大

最初的排查很传统：抓几个 core dump，看寄存器、栈帧、调用链，提出假设，再排除假设。

这像医生看病。问题是，系统规模一大，单个病例很容易骗人。

OpenAI 一开始也被带偏。崩溃跨区域、跨硬件类型出现，硬件问题看起来不像主因。部分代码路径似乎没用异常处理，exception unwinding 也一度被排除。

后来他们把过去一年生产环境里的 Rockset core dump 自动化下载、解析、打标签。标签包括 return-to-null、misaligned-stack 和其他崩溃。

再看区域、时间、集群、硬件相关性。

数据一干净，故事就变了。

两个根因，不能混在一起讲

misaligned-stack 崩溃集中在一个区域，有清楚起点，只发生在某些新启动节点上。

表面上，它涉及多个 Azure VM。继续往下看，模式指向同一台物理宿主机。

这很关键。材料只支持“一台 Azure 物理宿主机出现静默错误”，不支持“Azure 大规模硬件失效”。

这类问题可怕的地方也在这里：它不一定大面积爆炸，但会悄悄污染你的排查判断。像一段坏轨道，谁的车厢经过，谁出事。

return-to-null 是另一回事。

它分散在多个集群和地区，没有整齐边界。剥离硬件问题后，OpenAI 才看到这些崩溃发生在 C++ 异常展开过程中，最终指向 GNU libunwind 的长期竞态。

注意，这不是 OpenAI 自己代码写了 18 年 bug。它在 GNU libunwind 这个广泛使用的开源底层库里。

这就是基础设施事故最难受的部分：业务层看到的是崩溃，真正的裂缝可能在云硬件、开源库、运行时、编译器 ABI 或异常机制之间。

早期铁路和电网事故也有类似味道。系统越大，事故越不像“一个零件坏了”，越像轨道、调度、信号、维护同时露边。

今天换成了云主机、C++ ABI、异常展开、容器节点和 core dump 管线。不完全一样，但重复的是同一种结构：规模把小概率问题抬到了桌面上。

“天下大事，必作于细。”放到 AI 基础设施里，就是一句很朴素的话：模型越往上长，底座越不能靠祈祷。

真正该学的，是把鬼故事变成数据集

这篇博客最有价值的地方，不是结论多神奇，而是方法很硬。

OpenAI 没有继续把每个 core dump 当悬案。他们把崩溃样本变成数据集，再按类型、时间、区域、集群、硬件去找分布。

这就是“故障流行病学”。

医生模式问：这个病人为什么倒下。

流行病学模式问：这类病在人群里怎么分布，是否集中在某个地点、时间、群体或暴露条件下。

AI 基础设施正在逼团队走向后者。

因为 ChatGPT 这类产品背后不是一个模型在孤独运行。它后面有检索系统、数据索引、云硬件、开源库、运行时、控制平面和复制机制在接力。

任何一层露出半毫米缝，最后都可能表现成“服务不稳定”。

对 SRE 和基础架构团队，动作很具体：core dump 不能只当临时证据，要能长期留存、自动解析、统一打标签；硬件、区域、集群、时间这些维度要能连起来查。

对后端和 C++ 工程师，重点是别太快把“诡异崩溃”归咎于业务代码。异常展开、unwinding、运行时库和 ABI 边界都要进入排查清单。

对工程管理者，决策也很现实：稳定性投入不能只买监控大屏。真正值钱的是故障样本库、归因管线、依赖清单和隔离机制。

这不是采购一套工具就结束。约束也很明显：core dump 可能涉及敏感数据，存储和访问要受控；标签体系一开始也不会完美，需要工程师不断校准。

但没有这套东西，团队会反复被“低概率、高迷惑性”的事故教育。

我不太买账那种轻飘飘的 AI 叙事：模型更强，agent 更聪明，系统自然更可靠。

现实更拧巴。模型越强，调用越复杂；链路越长，灰区越多。

真正难的不是做一个 demo，而是让数十亿次调用穿过一堆不完美部件，还能稳定返回。

接下来最该观察的，也不是 OpenAI 会不会再写一篇漂亮博客。

该看三件事：这类 crash 分析是否会变成常规基础设施；开源底层库的竞态修复和依赖升级能否被快速吸收；云上静默硬件错误能否被更早隔离，而不是等业务崩溃来报信。

模型公司常被外界用参数、榜单、推理速度衡量。可大规模 AI 产品的另一条分水岭，藏在更不性感的地方：core dump 有没有留住，标签准不准，坏节点能不能隔离，运行时依赖到底是谁覆盖了谁。

模型看着在天上飞，事故经常从地下冒出来。