OpenAI が core dump 解析で18年越しの libunwind 不具合を修正

OpenAI は 2026-06-30 に「Core dump epidemiology: fixing an 18-year-old bug」を公開しました。Rockset を使った ChatGPT のデータ検索基盤で発生していたまれな C++ クラッシュを、core dump の集団分析で調査し、Azure ホストの異常と GNU libunwind の古い競合不具合を切り分けた技術記事です。

要点

• Rockset のクエリ処理ノードで起きたクラッシュを、個別の core dump 調査から全体傾向の分析へ切り替えて原因特定しています。
• 一つの不具合に見えていた現象を、Azure の特定ホストに由来するレジスタ破損と、GNU libunwind の 18 年越しの競合不具合に分けています。
• 大規模な AI サービスを支える検索・データ基盤で、クラッシュ情報をどう収集し、分類し、再発検知へつなげるかを示す事例です。

今回のブログ記事で語られていること

今回のブログ記事は、ChatGPT が関連データを検索したり、会話やワークスペースの知識ベースを参照したりするために使われる Rockset 系のデータインフラで起きたクラッシュ調査を扱っています。Rockset は検索とリアルタイム分析のためのデータシステムで、OpenAI は 2024 年に同社を買収しています。記事では、C++ で書かれた実行層が高い性能と省メモリ性を得られる一方、メモリ安全性の問題や低レイヤーのランタイム不具合に弱いことが背景として説明されています。

最初の調査では、クラッシュしたプロセスの core dump を個別に読み、壊れた stack frame や %rsp のずれ、NULL の return address などを追っています。しかし、個別事例だけでは「一つの奇妙な不具合」に見えてしまい、ログ検索でも false positive と false negative を避けられませんでした。転機になったのは、過去 1 年分の production Rockset core dump をまとめて処理し、return-to-null、misaligned-stack、その他のクラッシュとして自動分類するデータセットを作ったことです。そこから、クラッシュには二つの別集団があると分かります。

一つ目は、特定の Azure 物理ホストに由来すると思われるレジスタ破損です。複数の VM にまたがって見えていたため最初はハードウェア起因と判断しづらかったものの、core dump の発生時刻と Kubernetes node の対応を追うことで、問題のホストを denylist できました。OpenAI は同種の事象をログだけで検知しやすくするため、fatal signal handler にレジスタ状態を含める改善も入れています。

二つ目は、GNU libunwind に残っていた 18 年越しの race condition です。C++ の exception unwinding では、実行時に stack をたどり、cleanup handler や catch block へ制御を移します。記事では、GNU libunwind の _Ux86_64_setcontext が stack 上に作った ucontext_t を参照しながら %rsp を更新するため、ちょうどその一命令幅の窓で signal が届くと、まだ読む予定だったデータが signal frame に上書きされうることを説明しています。OpenAI の Rockset では、高頻度の exception、CPU 時間計測のための SIGUSR2、signal handler の stack 使用量が重なり、この非常に狭い競合が運用上見える頻度になりました。最終的には libgcc の unwinder へ切り替え、GNU libunwind へ再現コードと修正も upstream しています。

この記事の主眼は、まれなクラッシュを「たまたま起きた不可解な障害」として扱わず、母集団全体を見て症状を分けることにあります。OpenAI はこれを医師のように一つの症例を見る調査から、疫学者のように集団の分布を見る調査へ切り替えた、と説明しています。AI サービスではモデルや機能の発表が目立ちますが、実際の信頼性は、クラッシュ時の証跡を保存し、同種の失敗をまとめ、OS・ランタイム・ライブラリ・ハードウェアの境界まで原因を追える運用にも支えられています。

今回のブログ記事が関係する人

AIサービス、検索基盤、分散システム、データ処理基盤を運用するプラットフォームエンジニア、SRE、バックエンドエンジニアに関係します。特に、C++ や Rust など低レイヤーの実行基盤、core dump、signal、exception、コンテナ基盤、クラウド VM を扱うチームに向いた内容です。

実務で確認したいポイント

• core dump や fatal signal handler の出力を、原因調査に使える粒度で安全に保存できているかを確認します。
• クラッシュログを個別に読むだけでなく、ホスト、リージョン、VM、kernel、binary、ライブラリ版、発生時刻で集計できる状態にします。
• 再現しづらい低頻度障害について、ハードウェア、OS、実行時ライブラリ、アプリケーションコードを分けて疑えるランブックを用意します。
• signal handler、exception、unwinder、CPU accounting のような低レイヤー機構を組み合わせる場合、まれな相互作用を観測できるようにします。
• 障害解析で扱う dump やログに機密情報が含まれる可能性を前提に、収集・保管・アクセス権限のルールを整えます。

結局、今回のブログ記事をどう読むべきか

このブログ記事は、OpenAI が ChatGPT を支えるデータ検索基盤で、不可解なクラッシュをどのように切り分けたかを示す技術事例です。重要なのは、core dump を少数の症例として読むだけではなく、クラッシュ全体の母集団を作り、別々の原因を持つ集団へ分解した点です。大規模な AI / データ処理システムを運用するチームは、クラッシュ情報を捨てずに分析へつなげる仕組み、低頻度障害を長期で追う仕組み、修正後に同じ系統の問題が再発していないかを見る仕組みを点検する材料として使えます。