---
title: "コアダンプを『疫学』的に分析したら、18年も隠れてたlibunwindのバグを見つけちゃったの！"
source: "OpenAI"
source_url: https://openai.com/index/core-dump-epidemiology-data-infrastructure-bug
published_at: 2026-06-30T00:00:00+00:00
tags: ["openai","infrastructure","devops"]
---

# コアダンプを『疫学』的に分析したら、18年も隠れてたlibunwindのバグを見つけちゃったの！

やっほー、しぃちゃんだよ！今日はOpenAIが公開した、まるでミステリー小説みたいなデバッグ体験記を紹介するね。地味なタイトルに見えるかもしれないけど、読んでみたらすっごくわくわくする話だったから、みんなにも早く届けたいの！

## なにが発表されたの？

OpenAIは2026年6月30日、社内のデータ基盤で長らく発生していた原因不明のクラッシュを、どうやって突き止めて直したかを詳しく紹介する記事を公開したよ。舞台になったのは、OpenAIが2024年に買収したリアルタイムデータ基盤「Rockset」なの。ChatGPTの検索機能やデータプラグイン機能を裏側で支えている、けっこう大事なシステムなんだ。

このクラッシュ、C++のプログラムが実行中に、なぜか壊れたアドレスやNULLアドレスへ処理を飛ばしてしまう、という不気味な症状だったみたい。しかも発生頻度がとても低くて、狙って再現させることができなかったんだって。最初はエンジニアたちも「1つの謎バグ」として扱っていたそうだよ。

そこでチームは、個々のクラッシュを1件ずつ深追いするんじゃなくて、まるで疫学者が病気の集団発生を調べるみたいに、過去1年間にRocksetで生成された全部のコアダンプを対象にした自動分析パイプラインを作ったの。しかもこのパイプライン、一部はChatGPT自身に書かせたんだって。これはOpenAIらしいエピソードだよね。

## 今までどうだったの？

これまでのインフラのデバッグって、基本は「クラッシュが起きたら、そのコアダンプを1つずつ人間が読み解く」というスタイルだったの。でも今回みたいに発生頻度が低くて再現もできない不具合だと、1件ずつ見ていても「同じバグの別パターン」なのか「実は無関係な複数のバグ」なのか区別がつきにくいんだよね。実際、今回のケースも最初は単一の原因だと思われていて、それが調査を長引かせる一因になっていたみたい。

## これからどうなるの？

大量のコアダンプをまとめてダウンロード・解析・分類するパイプラインを作って、レジスタの情報などを抽出しながら母集団として統計的に見てみたら、なんと「1つに見えていたバグ」が、実は無関係な2つの原因による、別々のクラッシュ集団だったことがはっきり分かったの。個別に追っていたら見えなかった相関が、集団で見た瞬間にくっきり浮かび上がった、というのが今回のハイライトだよ。

この結果、Rocksetのクラッシュはしっかり原因を切り分けて対処できるようになったの。それだけじゃなくて、原因の1つだったlibunwindという業界で広く使われているオープンソースライブラリの不具合は、OpenAI社内にとどめずアップストリーム(本家プロジェクト)にフィードバックされたんだって。同じライブラリを使っている他の高スループットなC++サービスにとっても、恩恵があるかもしれないね。

## Dive Deep

ここからは技術好きのみんなのために、しっかり深掘りするね。

見つかった原因は次の2つだよ。

1. **ハードウェア故障**: 特定の物理Azureホスト1台で起きていた、検出しにくいサイレントなハードウェア破損。CPUの計算そのものがおかしくなっていたタイプの障害だったみたい。
2. **GNU libunwindのレースコンディション**: C++の例外処理でスタックを巻き戻す(アンワインドする)ために業界で広く使われているオープンソースライブラリ「GNU libunwind」に、18年以上前――x86_64向けにC++の例外アンワインドをサポートした最初期のバージョンから存在していた競合状態(レースコンディション)が見つかったの。

複数の海外メディアの報道によると、この競合状態はスタックポインタを更新する命令と、戻り先の命令ポインタを読み込む命令の間にごく短い隙間(すきま)があり、そのタイミングでシグナル割り込みが入ると、復元される命令ポインタが壊れてしまう、という仕組みだったそう。OpenAIの環境ではCPU使用量をシグナルベースで計測する仕組みを使っていたこともあって、この極めてまれな競合が表面化しやすかった、という説明もあるよ。対応としては、Rockset側のアンワインダーを別の実装(libgccのアンワインダー)に切り替えることで回避しつつ、libunwind本家には再現手順と修正案がフィードバックされたと伝えられているの。

こうした深掘りができたのも、1件ずつのクラッシュを追うんじゃなくて、1年分という大きな母集団のコアダンプをまとめてダウンロード・解析・分類する自動パイプラインを作ったからこそ。既知の誤検知(ノイズ)をフィルタして、クリーンなデータセットにした瞬間に相関がくっきり見えてきた、というのは、大規模インフラのデバッグ手法としてすごく汎用性が高いアプローチだと思うな。

## まとめ

今日は、OpenAIがRocksetの原因不明クラッシュを、コアダンプの「疫学」的な集団分析で突き止めたお話を紹介したよ。1つに見えていたバグが、実は「Azureホスト1台のハードウェア故障」と「libunwindの18年物レースコンディション」という、全然関係ない2つの原因だったなんて、しぃちゃんもびっくりしちゃった。しかもその修正を業界標準のライブラリ本家にちゃんと還元しているところが、すごく誠実だなって感じたよ。地味に見えるインフラのデバッグ話だけど、発想の転換ひとつで長年の謎が解けちゃうのって、本当にロマンがあるよね。

原文はこちらだよ: [Core dump epidemiology: fixing an 18-year-old bug](https://openai.com/index/core-dump-epidemiology-data-infrastructure-bug)