コアダンプを「疫学」的に分析したら、18 年も潜んでいた libunwind のバグを発見！
やっほー、しぃちゃんだよ！今日は OpenAI が公開した、まるでミステリー小説みたいなデバッグ体験記を紹介するね。地味なタイトルに見えるかもしれないけど、読んでみたらすっごくわくわくする話だったから、みんなにも早く届けたいの！
OpenAI News
openai.com
なにが発表されたの？
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++サービスにとっても、恩恵があるかもしれないね。
深く潜ってみよう
ここからは技術好きのみんなのために、しっかり深掘りするね。
見つかった原因は次の 2 つだよ。
- ハードウェア故障: 特定の物理 Azure ホスト 1 台で起きていた、検出しにくいサイレントなハードウェア破損。CPU の計算そのものがおかしくなっていたタイプの障害だったみたい。
- GNU libunwind のレースコンディション: C++の例外処理でスタックを巻き戻す(アンワインドする)ために業界で広く使われているオープンソースライブラリ「GNU libunwind」に、18 年以上前――x86_64 向けに C++の例外アンワインドをサポートした最初期のバージョンから存在していた競合状態(レースコンディション)が見つかったの。
複数の海外メディアの報道によると、この競合状態はスタックポインタを更新する命令と、戻り先の命令ポインタを読み込む命令の間にごく短い隙間(すきま)があり、そのタイミングでシグナル割り込みが入ると、復元される命令ポインタが壊れてしまう、という仕組みだったそう。OpenAI の環境では CPU 使用量をシグナルベースで計測する仕組みを使っていたこともあって、この極めてまれな競合が表面化しやすかった、という説明もあるよ。対応としては、Rockset 側のアンワインダーを別の実装(libgcc のアンワインダー)に切り替えることで回避しつつ、libunwind 本家には再現手順と修正案がフィードバックされたと伝えられているの。
こうした深掘りができたのも、1 件ずつのクラッシュを追うんじゃなくて、1 年分という大きな母集団のコアダンプをまとめてダウンロード・解析・分類する自動パイプラインを作ったからこそ。既知の誤検知(ノイズ)をフィルタして、クリーンなデータセットにした瞬間に相関がくっきり見えてきた、というのは、大規模インフラのデバッグ手法としてすごく汎用性が高いアプローチだと思うな。
まとめ
今日は、OpenAI が Rockset の原因不明クラッシュを、コアダンプの「疫学」的な集団分析で突き止めたお話を紹介したよ。1 つに見えていたバグが、実は「Azure ホスト 1 台のハードウェア故障」と「libunwind の 18 年物レースコンディション」という、全然関係ない 2 つの原因だったなんて、しぃちゃんもびっくりしちゃった。しかもその修正を業界標準のライブラリ本家にちゃんと還元しているところが、すごく誠実だなって感じたよ。地味に見えるインフラのデバッグ話だけど、発想の転換ひとつで長年の謎が解けちゃうのって、本当にロマンがあるよね。
