核心转储流行病学：修复一个存在18年的漏洞

这篇文章讲述了OpenAI如何通过对出现的崩溃进行分析，找到并修复了两个复杂的bug。这些崩溃来自于我们数据基础设施的Rockset服务，后者对许多数据插件和对话搜索至关重要。我们通过对整个崩溃数据集的分析，发现了问题的根源。

## 问题背景
OpenAI的模型和代理越来越依赖可扩展的数据基础设施，以在推理时搜索相关数据。我们的许多服务使用C++编写，这样能够最大限度地提升性能并减少内存使用。然而，C++缺乏内存安全性，导致可能出现崩溃，尤其是写入错误或不存在的内存地址。

几个月前，我们观察到Rockset服务内部的一些崩溃。每次崩溃似乎都是一个正常的C++函数完成后返回了一个虚假的地址，导致程序停滞。经过几个月的努力，我们发现这些崩溃的根源在于一个年龄已达18年的race condition以及硬件故障。

## 调试尝试
我们最初的方法是仔细检查几个核心转储文件，进行假设并逐一排除。在某些崩溃中，出错的函数似乎在调用某个未知的函数时，堆栈被破坏，最后返回了一个不可执行的地址。

我们曾尝试使用应用程序级别的日志来识别问题的所有出现情况，但由于堆栈损坏，日志无法精确分类。经过多次手动检查后，我们开始意识到问题的复杂性。当我们重新审视这些核心转储，尤其是标记清晰的崩溃数据时，情况开始好转。

## 关键发现
最终，我们意识到之前我们一直将两个不同的bug混为一谈。第一个问题是硬件故障导致的misaligned-stack崩溃，第二个是libunwind库中的异常处理问题。在对剩余崩溃的分析中，我们发现它们实际上是发生在异常解除时。

经过深入研究，我们终于确定了这两个bug的根源，分别为硬件问题和libunwind库的竞争条件。解决方案是移除坏主机并对软件进行改进，以防止类似问题再次发生。

## 总结
这次经历教会了我们不能只是集中精力看单一案例，而要从整体上分析数据。在这个过程中，我们不仅找到了bug并进行了修复，也提升了我们的调试能力和数据处理水平。

---

原文链接：[点击查看](https://openai.com/index/core-dump-epidemiology-data-infrastructure-bug)