bingdadaOpenAI工程师通过群体分析方法，修复了Rockset服务中看似不可能的崩溃问题。该问题由两个独立bug引起：一个Azure主机上的硬件损坏和GNU libunwind中一个18年的竞态条件。文章详细描述了从传统调试到流行病学分析的转变过程。
OpenAI的模型和代理越来越依赖可扩展的数据基础设施，以便在推理时（即模型思考你的问题时）搜索相关数据。其中一些服务是用C++编写的，C++对系统的底层控制使我们能够最大化性能并最小化内存使用。随着规模扩大，这些效率优势变得至关重要，但C++缺乏内存安全性意味着bug可能通过写入错误或不存在的内存地址导致崩溃。 几个月前，我们观察到Rockset服务出现了一些崩溃。Rockset是ChatGPT数据基础设施中的一个定制部分，对许多数据插件和搜索对话历史至关重要。在每次崩溃中，一个正常的C++函数似乎执行完毕后返回了一个虚假地址，导致内核停止程序，因为指令指针不再指向代码。有时栈帧中的返回地址槽为NULL。有时栈指针CPU寄存器本身似乎偏移了8字节，就好像%rsp在正常执行过程中被错误地减少了。在这两种情况下，崩溃都发生在返回时。 这些不是应用程序代码的正常故障模式。只落在保存的返回地址上的随机写入是可能的，但极不可能。一个不涉及内联汇编、setcontext或longjmp（我们都不使用）的bug将%rsp错位8字节更加奇怪，因为编译后的代码只在函数序言和尾声直接调整该寄存器。我们（或ChatGPT）能想到的每个假设都有强有力的证据反对它，所以这个bug似乎不可能存在。 我们最初认为的一个问题最终被证明是两个不相关的bug，巧合的是同时被发现。首先，一个Azure主机上的静默硬件损坏，CPU无法正确进行数学运算。其次，GNU libunwind中一个18年的竞态条件，这是一个广泛使用的开源库中未被注意的bug。 这篇文章讲述了我们如何通过像流行病学家一样思考并构建关于整个崩溃群体的高质量数据集，来识别和修复看似无法解释的崩溃。
首先，让我们深入了解Rockset。它是一个用于搜索和实时分析的云原生数据系统，我们在OpenAI内部用于许多用例，比如同步连接器（Rockset于2024年被OpenAI收购）。流式更新用于维护工作区知识库的最新索引，以便ChatGPT在回答问题或执行操作时可以搜索相关信息。 Rockset的执行层是用C++编写的。C++语言提供了对CPU的低级访问，这对性能和效率有好处，但也意味着应用程序bug可能导致无效内存访问和段错误。为了帮助追踪这些问题，我们使用folly的致命信号处理程序在崩溃发生时记录堆栈跟踪，并将相应的核心转储（程序崩溃时状态快照）上传到Azure blob存储以供后续分析。Rockset的所有查询处理副本都是复制的，这最小化了崩溃对客户端的影响。然而，每个段错误对应一个需要修复的bug，以满足我们的可靠性和质量目标。 我们最初的方法是将这些核心转储视为传统调试问题：非常仔细地检查几个核心转储，形成假设，并逐一排除。 大多数崩溃发生在名为DocumentTree::updateDocument的方法中。在这些崩溃中，似乎updateDocument调用了某个未知函数X，当X活动时堆栈被损坏，然后X返回了一个不是可执行代码的地址。在某些情况下，X刚刚弹出的帧看起来有效，只是其保存的返回地址为NULL。在其他情况下，栈指针本身看起来错误，但下一个有效帧似乎仍然是updateDocument。 我们不知道堆栈何时被损坏，这留下了巨大的搜索空间。updateDocument是一个大型方法，经过大量内联，所以X的候选数量是压倒性的。 这是我们的C++代码中的bug吗？编译器或链接问题？我们的运行时库之一有问题？Linux内核关于信号传递或上下文切换的bug？还是更罕见的情况？如果是随机写入，为什么我们的ASAN暂存环境没有捕获到？ 我们尝试使用应用程序级日志来识别所有问题发生的情况，但堆栈损坏的bug仅从日志中很难分类，因为记录的堆栈跟踪本身被损坏或丢失。我们无法构建一个既没有误报也没有漏报的日志查询。我们手动检查了更多核心转储，发现了一些额外示例，但这个过程过于劳动密集，无法给我们一个可信的数据集。 在调查的这个阶段，我们（错误地）排除了硬件bug，因为我们在多个区域和多种硬件类型上看到了崩溃，所以我们仍在寻找仅软件的原因。有几天，我们深入研究了单个%rsp错位的崩溃，使用堆栈和寄存器内容重建崩溃前的历史。这产生了一些可能的线索，但因为我们在最初结论上坚持认为所有bug都有相同原因，这并没有让我们摆脱困境。
在谈到调查的转折点之前，重要的是解释我们从核心文件中提取了哪些信息。 Rockset使用-fno-omit-frame-pointer编译，因此活动栈帧始终可以通过%rbp访问，调用者形成帧指针的链表。 在Linux x86_64上，AMD64 System V ABI
Bingdada 是一个专注 SEO、GEO（生成式引擎优化）与 AEO（答案引擎优化）的内容平台，由资深内容编辑、SEO 技术工程师与 AI 研究专家组成的团队持续运营。我们追踪搜索引擎与生成式 AI 的最新动态，为读者提供准确、实用、可落地的方法论与行业洞察。 编辑团队：内容策划 · 技术编辑 · AI 研究组 网站：bingdada.com © 2026 Bingdada. 保留所有权利。
SEO & GEO 技术探索者，专注于搜索引擎优化和生成式引擎优化。
英伟达内部实践显示，ChatGPT Work正帮助企业团队将信息整合工作自动化，每周节省16小时，并将原型开发周期从数周缩短至数天。这一案例揭示了AI工作流从工具到组织资产演进的趋势。
OpenAI 将 GPT-5.6 系列模型（Sol、Terra、Luna）集成至 Kiro 开发代理，通过规格驱动方法实现约 82% 的成本降低，标志着 AI 编程从能力竞赛转向成本效率竞争。
OpenAI因模型网络能力逼近关键门槛而调整开发策略，强调安全需贯穿训练全周期。文章解析其技术升级，并对比国内AI安全建设路径。
获取最新的 SEO 与 GEO 技术资讯。
我们尊重您的隐私，随时可以取消订阅。
