OpenAIは2026年6月30日、ChatGPTのデータインフラで使用しているRocksetサービスで発生していた謎のクラッシュの原因究明と修正のプロセスを技術ブログで公開した。調査の結果、ハードウェアの不良とGNU libunwindの18年前のバグという、まったく無関係な2つの問題が同時に発生していたことが判明した。
問題の発端は、C++で実装されたRocksetサービスで、実行中の関数が無効なアドレスに戻ろうとするクラッシュが頻発したことだった。スタックポインタのずれやNULLへのリターンという通常ありえない症状が重なり、当初は原因の特定が困難を極めた。転機となったのは「医師的なアプローチ（個別ケースの深掘り）」から「疫学者的なアプローチ（クラッシュ全体の集団分析）」への転換だ。ChatGPTを使って書いたスクリプトで過去1年分のコアダンプを自動解析したところ、2種類のクラッシュ集団が浮かび上がった。1つは特定のAzure物理ホスト上にのみ発生しており、CPUが演算を正しく実行しないハードウェア不良と判明。もう1つはC++例外処理の巻き戻し（アンワインド）中に発生しており、GNU libunwindの競合状態（レースコンディション）が原因だった。
GNU libunwindのバグは、レジスタを復元するアセンブリコードで%rspを更新した直後の「1命令分の隙間」にシグナルが割り込むと、復元先アドレスが破壊されるというものだ。発生確率は約10⁻⁸/例外と極めて低いが、Rocksetでは過負荷制御のために例外を毎秒1万回規模で発生させるという特殊な使い方をしており、結果として1台のホストで数時間に1回のクラッシュが生じていた。対策としてGNU libunwindからlibgccのアンワインダーへの切り替えを即時実施し、GNU libunwindにも修正パッチを提供している。
「集団分析」が個別調査を上回る場面
今回の調査で特徴的なのは、個別ケースの詳細な解析に数日を費やしても解決しなかった問題が、全クラッシュのデータ集約によって数時間で構造を見抜けるようになった点だ。2つの無関係なバグが混在していたために個別分析では矛盾する証拠が生まれ、論理的な推論を妨げていた。インフラ障害の調査において集団レベルの可視性を持つことの価値が改めて浮き彫りになった事例といえる。
「使い方の特殊さ」が潜在バグを顕在化させた構図
GNU libunwindのバグは18年間存在していたが、Rocksetの3つの特異な条件——高頻度の例外送出・SIGUSR2の頻繁な配信・シグナルハンドラのスタック使用量の増大——が重なって初めて発現した。汎用ライブラリが高負荷・高頻度シグナル環境では想定外の挙動をしうるという教訓は、大規模インフラを独自の方法で利用する事業者に広く共通する課題として注目される。
オープンソースへの還元が示す運用姿勢
自社の問題を修正するだけでなく、GNU libunwindに再現コードと修正パッチを提供した点も見逃せない。同ライブラリは多くのLinuxシステムで使われており、今回の修正は他の利用者にも恩恵をもたらす。大規模なサービス運用を通じて発見した知見をコミュニティへ還元するという姿勢は、技術的信頼性の観点からもブランディングの観点からも機能している。
