コアダンプ疫学：18 年前のバグを修正

OpenAI のモデルやエージェントは、推論時に（つまり、モデルがあなたの質問について考えている際に）関連データを検索するために、スケーラブルなデータインフラストラクチャにますます依存しています。これらのサービスの一部は C++ で書かれており、そのシステムへの低レベルの制御により、パフォーマンスを最大化しメモリ使用量を最小化できます。この効率性のメリットはスケールする上で重要ですが、C++ にはメモリの安全性がないため、バグが誤ったまたは存在しないメモリアドレスへの書き込みによってクラッシュを引き起こす可能性があります。 数ヶ月前、ChatGPT のデータインフラストラクチャの独自部分であり、多くのデータプラグインや会話内検索に不可欠な Rockset サービス内部からいくつかのクラッシュを観察しました。これらの各クラッシュにおいて、通常の C++ 関数が終了した後に偽のアドレスへ戻ろうとし、その結果、命令ポインタがもはやコードを指さなくなったためカーネルがプログラムを停止させました。場合によっては、スタックフレーム内の戻りアドレススロットが NULL になっていました。また、場合によっては、スタックポインタ CPU レジスタ自体が 8 バイトずれているように見え、%rsp が通常の実行の途中で何らかの理由で減算されたかのように見えました。どちらの場合も、クラッシュは関数からの戻り時に発生しました。 これらはアプリケーションコードにおける通常の故障モードではありません。保存された戻りアドレスのみに誤って書き込まれる stray write は起こり得ますが、極めて稀です。インラインアセンブリ、setcontext、longjmp（いずれも使用していません）を伴わずに %rsp を 8 バイトずらすバグはさらに奇妙です。なぜなら、コンパイルされたコードがそのレジスタを直接調整するのは関数のプロローグとエピローグのみだからです。私たちが（あるいは ChatGPT が）考え得たすべての仮説には強い反証があり、このバグは不可能に見えました。 我々が一つの問題だと考えていたものは、実は同時に偶然発見された二つの無関係なバグでした。第一に、ある Azure ホストでの静かなるハードウェア破損で、CPU が正しく計算を行っていなかったこと。第二に、広く使われているオープンソースライブラリである GNU libunwind（GNU libunwind）における 18 年前の競合条件（race condition）であり、見過ごされていたバグでした。 この投稿は、疫学者のように考え、すべてのクラッシュの母集団に関する高品質なデータセットを構築することで、説明不能に見えるクラッシュを特定し修正した物語です。 ## 最初のデバッグ試行：いくつかのコアダンプの慎重な検討 まず、Rockset について詳しく見ていきましょう。Rockset は検索とリアルタイム分析のためのクラウドネイティブデータシステムで、OpenAI では多くの内部ユースケースに使用されています。例えば同期コネクタなどです（Rockset は 2024 年に OpenAI に買収されました）。ストリーミング更新は、ワークスペースのナレッジベースのインデックスを最新の状態に保つために用いられ、ChatGPT が質問への回答やアクション実行時に関連情報を検索できるようにしています。 Rockset の実行層は C++ で書かれています。C++ は CPU への低レベルアクセスを提供するため、パフォーマンスと効率性に優れていますが、その反面、アプリケーションのバグがメモリへの不正なアクセスやセグフォルト（segfault）を引き起こす可能性があります。これらの問題を特定するために、クラッシュ発生時にスタックトレースをログ出力する folly の致命的シグナルハンドラを使用し、対応するコアダンプ（プログラムがクラッシュした時点の状態のスナップショット）を Azure Blob Storage にアップロードして後で分析しています。Rockset のクエリ処理のすべてのレイヤーはレプリケーションされており、これによりクライアントへのクラッシュの影響を最小限に抑えています。しかし、各セグフォルトは信頼性と品質目標を達成するために修正すべきバグに対応しています。 当初のアプローチは、これらのコアファイルを従来のデバッグ問題として扱うことでした：いくつかのコアダンプを非常に詳しく検査し、仮説を立てて、一つずつ除外していくという方法です。 クラッシュの大部分は DocumentTree::updateDocument というメソッド内で発生していました。これらのクラッシュでは、updateDocument が不明な関数 X を呼び出し、X 実行中にスタックが破損し、その後 X が実行可能なコードではないアドレスにリターンしたように見えました。場合によっては、直前にポップされた X のフレームは有効に見えたものの、保存された戻り先アドレスが NULL でした。他のケースではスタックポインタ自体がおかしいように見えましたが、次の有効なフレームはまだ updateDocument であるようでした。 スタックがいつ破損したのか分からず、調査範囲は非常に広範でした。updateDocument は大規模なメソッドであり、多くのインライン展開が行われるため、X の候補となるものが膨大すぎて対応しきれませんでした。 これは C++ コード内のバグでしょうか？コンパイラやリンケージの問題でしょうか？ランタイムライブラリのいずれかの不具合でしょうか？シグナル配信やコンテキストスイッチに関する Linux カーネルのバグでしょうか？あるいはもっと稀な事象でしょうか。もしこれが誤った書き込み（stray write）なら、なぜ ASAN 検証環境で検出されなかったのでしょうか。 アプリケーションレベルのログを使用して問題の全発生箇所を特定しようと試みましたが、スタック破損バグはログだけでは分類が困難です。記録されたスタックトレース自体が破損していたり欠落しているためです。偽陽性と偽陰性の両方を含んでいないログクエリを構築することはできませんでした。手動でさらに多くのコアファイルを調査し追加の事例を見つけましたが、このプロセスは信頼できるデータセットを得るにはあまりにも労力が必要でした。 調査のこの段階では、複数のリージョンや複数のハードウェアタイプでクラッシュが発生していることから（誤って）、ハードウェアバグを除外しました。そのため、ソフトウェア固有の原因を探し続けていました。数日間は単一の整列ミスによる%rsp クラッシュに徹底的に取り組み、スタックおよびレジスタの内容を用いてクラッシュ前の履歴を再構築しました。これによりいくつかの手がかりが得られましたが、すべてのバグに共通する原因があるという当初の結論から離れなかったため、事態は進展しませんでした。 ## スタックからの手がかり 調査の転換点に到達する前に、コアファイルからどのような情報を抽出していたのかを説明しておくことが重要です。 Rockset は -fno-omit-frame-pointer オプションでコンパイルされているため、アクティブなスタックフレームは常に %rbp を通じてアクセス可能であり、呼び出し元はフレームポインタの連結リストを形成します。 Linux x86_64 において、AMD64 System V ABI はまた、%rsp の下に 128 バイトをレッドゾーンとして予約しています。この領域はユーザー空間コードに利用可能であり、重要なのは、ABI の契約の一部として、カーネルがシグナルを配信する際にこれを上書きしないことを約束している点です。 レッドゾーンは、戻り後のクラッシュのデバッグにおいて中心的な役割を果たしました。なぜなら、それは戻りの前の情報をいくつか保持しているからです。SIGSEGV がトリガーされると、folly の致命的なシグナルハンドラがクラッシュしたスレッドのスタック上で実行されます。その関数が既に終了しているためもはやアクティブではないスタックフレームは、シグナルハンドラによって上書きされてしまいますが、最後の 128 バイトは例外です。そのため、「X の直前にポップされたスタックフレームは有効に見えたが、NULL の戻りアドレスを除いて」といったことが言えるのです。レッドゾーンは、いくつかの非アクティブなフレームを保持するか、あるいは単に一つの非アクティブなフレームの末尾部分を保持します。 関与するすべての関数が非常に小さかった 1 つのスタックアライメントミスによるクラッシュを見つけました。これにより、比較的単純な関数の実行中に %rsp がアライメントを失ったこと、その後にさらに多くの呼び出しが成功したことがわかりました。プログラムは、アクティブな関数が finally 戻ろうとしたときにのみクラッシュしました。これらのコードパスのいずれも例外、インラインアセンブリ、setcontext、または longjmp を使用していませんでした。したがって、スタックポインタがコアファイルが示す通りに実際に変更されたのであれば、ユーザー空間コードにその問題を説明する妥当なバグは存在しません。 これが私たちをカーネルへと向かわせました。 Rockset は、多くのプログラムよりもはるかに積極的にシグナルを使用しています。クエリ実行はデータを交換する多数の軽量タスクに分割されています。これは高 QPS ワークロードを効率的に処理するために重要ですが、多くのクエリの作業が同じスレッドプールに多重化されるため、クエリごとの CPU アカウンティングが awkward になります。 私たちの解決策は、coarse_thread_cputime_clock と呼ばれるものであり、これはタスク境界ごとにサンプリングするに十分なほど安価に clock_gettime(CLOCK_THREAD_CPUTIME_ID, ...) を近似するものです。timer_create API は、CPU 時間の蓄積を含む時間の経過に関するいくつかの概念に基づいて、周期的なシグナル配信をスケジュールするために使用できます。私たちは、CPU 時間が数ミリ秒ごとに SIGUSR2 というシグナルが配信されるようにスケジュールし、その時点でシグナルハンドラーがスレッドローカル値を更新します。多くのタスクは実行中に粗いクロックが進むのを認識しないものの、すべてのデルタを合計することで、クエリの実際の CPU 時間に対する不偏推定量を得ることができます。 私たちが非常に頻繁にシグナルを配信するため、コンテキストスイッチやシグナル配信に関する稀なカーネルバグが妥当であるように思われました。私たちはバグレポート、カーネルソースコード、および Azure 固有のカーネルパッチを読むのに時間を費やし、ストレステストも行いました。しかし、関連すると思われるものは何も見つかりませんでした。 その時点で、私たちは一旦立ち止まり、異なるアプローチを試すことに決めました。 ## ドクターか疫学者か？ このような問題をデバッグするには、主に 2 つの広い方法があります。 1 つは、ある種の医師のように振る舞うことです：一人の患者に焦点を絞り、多くのテストを実行し、詳細な証拠から単一の症例を診断しようとします。 もう一つの手法は、疫学者のように振る舞うことです：個々の症例では見えないパターンがあるかどうかを調べるために、集団全体を見渡すのです。このバグは特定のリリースで始まったのでしょうか？特定のハードウェア SKU（特定の CPU とサーバーモデル）、特定のリージョン、あるいは特定のカーネルバージョンと相関関係があるのでしょうか？一見すると一つの症候群に見えるものの内部に、複数の異なるクラスターが隠れているのでしょうか？ 私たちは主に医師モードで活動していました。重要な転換点は、高品質な集団データを収集する必要があると決断したことです。 ## データのクリーニング 以前の問題のすべてのインスタンスを自動的に見つけようとした試みは失敗しました。その理由は、ログ上でのテキスト検索を使おうとしていたからです。コアダンプ自体にはより多くの情報が含まれていますが、それらを人手で確認する方法ではスケーラビリティが確保できませんでした。そこで、コアダンプを自動的に分析できるパイプラインを構築するために努力を投資することにしました。 ChatGPT に、各コアファイルのプレフィックスをダウンロードし、レジスタを抽出し、ログを用いて既知の偽陽性をフィルタリングし、クラッシュを「null への復帰」「スタックの不整合」、あるいはその他に自動的にラベル付けするスクリプトを作成させました。その後、過去一年間に発生したすべての本番環境における Rockset のコアダンプに対して、このスクリプトを並列実行しました。 これが転換点でした。 クリーンなデータセットが整った瞬間、相関関係が即座に浮かび上がりました。これまで私たちは一つの奇妙なバグとして扱っていたものが、実際には*二つ*の独立したクラッシュ集団であったことが判明したのです。 null への復帰コアは多くのクラスターや地理的領域に広がっていました。その頻度は最近増加していましたが、明確な開始日やクリーンなインフラの境界線はありませんでした。 スタックの不整合によるクラッシュは全く異なる様子を示していました。これらはすべて一つの地域から発生し、明確な開始日を有しており、長時間稼働しているノードでは決して発生しませんでした。複数の Azure VM（クラウド上でホストされる仮想マシン）が関与していましたが、そのパターンは不良ハードウェアを備えた単一の物理マシンが、たまたまそこに割り当てられたどの VM にも問題を引き起こしているように見えました。 これが、私たちが二つのバグを精神的に混同していたことに気づいた瞬間でした。両方のバグからの反例を混ぜて分析していたため、単一の整合性のある説明を見つけることができなかったのです。 ## バグ #1: 不良ホスト クリーンな Kubernetes ノードとタイムスタンプのリストを手に入れたことで、スタックの不整合クラッシュを単一の物理ホストに遡って追跡することができました。これは容易に除外リストに登録できるものでした。 そのホスト上で制御された環境においてレジスタ破損を再現することはできず、数週間にわたるストレステストを行っても同様でした。しかし、問題のあるホストが運用から外されると、スタックの不整合クラッシュは消滅しました。 悪いホストを除去するだけでは永続的な解決策にはなりません。なぜなら、同様の問題の再発を防ぐものではないからです。しかし、ソフトウェアを変更することで、同様の問題が再発した場合でも容易に検出・処理できるようにすることは可能です。致命的なシグナルハンドラーを改善し、レジスタ状態を含めることで、ログのみから再発を検出可能にし（コアダンプは不要）、制御プレーンを変更して通常は VM を再利用するようにし、リサイクルしないようにしました。これにより、インフラストラクチャスタックの当レベルでの悪いノード検出が格段に容易になりました。また、この可能性を考慮したランブック（およびチームのメンタルモデル）も更新しました。 悪いホストによるクラッシュを分離したことで、残りの null へのリターンコアは推論しやすくなりました。以前は例外の巻き戻しを除外しましたが、例外が確実に使用されていないコードパスでのクラッシュという反例があると考えたためです。しかし、その反例はすべてハードウェア破損クラスターからのものでした。 その点を踏まえて残りのコアを見直したところ、この結論は完全に逆であったことが分かりました：すべてのクラッシュは例外の巻き戻し中に発生していました。 例外処理は動的な制御転送です C++ で例外がスローされると、ランタイムはどの catch ブロックがそれを受け取るべきか、またその過程でどのデストラクタやクリーンアップハンドラーを実行すべきかを発見する必要があります。コンパイラはこのメタデータを生成しますが、実際のマッチングは実行時に動的に行われます。 例外の巻き戻しは、throw を呼び出す関数自体によって行われるのではなく、生成されたコンパイルコードによって呼び出されるヘルパー関数によって実行されます。これらのランタイムルーチンはスタックを検査し、スタック上に見つかった関数に関するメタデータを取得し、動的にクリーンアップハンドラとキャッチブロックを探し出し、その後制御をそれらの場所のいずれかに移します。制御の移行には、中間のすべてのスタックフレーム（ヘルパー関数のフレームを含む）の巻き戻しも含まれます。 運用上、これは通常の呼び出しと復帰よりも、longjmp やファイバー切り替えに非常に近いです。キャリー保存レジスタを復元するだけでなく、スタックフレームレジスタ %rbp と %rsp も復元する必要があります。 私たちのバイナリは、C++ 例外の巻き戻しを実行する関数の実装を含む 2 つのライブラリとリンクされています：libgcc と GNU libunwind です。GNU libunwind の定義が動的リンカーによって選択されました。これは私たちを驚かせました；シンボルバージョン管理規則のため、libgcc の実装が勝つだろうと考えていたからです。しかし、実行中のバイナリを検査した結果、そうではないことがわかりました。 最後の仮定を取り消す 現時点で、私たちが 1 つのバグしかないと考えていたときに設定していたもう一つの仮定を緩和したため、私たちの作業仮説は変更されました。 おそらく、通常の関数呼び出しの戻り先が NULL になっていたわけではありません。むしろ、unwind transfer（アンワインド転送）、つまり setcontext スタイルのレジスタ復元の一環として、制御が転送される前に宛先の命令ポインタが NULL 化していた可能性があります。言い換えれば、スタック上の戻りアドレススロット自体の誤りではなく、unwind ライブラリからの不正確なデータだったのです。 これにより問題の範囲は劇的に絞り込まれました。GNU libunwind が間違った宛先状態を計算しているのか、あるいは正しい状態を計算したものの、適用される前にそれが破損していたのかのどちらかです。 私たちは GNU libunwind のソースコードを読み込み、そこでスタック上に ucontext_t を合成し、クリーンアップハンドラのフレームに対する必要なレジスタ状態を埋め込んだ後、その構造体へのポインタを内部のアセンブリルーチンである _Ux86_64_setcontext に渡していることを発見しました。 この時点で、すべての手がかりが揃いました。 合成された ucontext_t は、_Ux86_64_setcontext 関数の実行中に、その関数によってアンワインドされるスタックフレームのいずれかに存在します。_Ux86_64_setcontext が %rsp を変更した後にこの構造体を読み込んでいたのでしょうか？もしそうであれば、その時点で構造体はもはやアクティブなスタックの一部ではなくなり、頻繁に発生する SIGUSR2 などのシグナル配信によって上書きされる脆弱性を抱えていたことになります。 ## Bug #2: the libunwind bug 答えは「はい」でした。 以下は、私たちが使用していたバージョンの GNU libunwind における _Ux86_64_setcontext の最後の 6 つの命令です。これらは主にメモリから宛先レジスタへデータをロードする mov 命令で構成されています： (%rdi はスタック割り当てされた ucontext_t を指しており、UC_MCONTEXT_* マクロは特定のレジスタが保存される固定オフセットに展開されます。) 最初の命令は競合ウィンドウの開始点です。これは %rsp を更新して、アクティブなスタックの新しい底部を指すようにします。この瞬間から、%rdi が指す構造体はもはやアクティブなスタック（またはレッドゾーン）の一部ではなく、カーネルによってアクセス可能になります。 通常これは問題を引き起こしませんが、信号がちょうどよい（あるいは悪い？）タイミングで到着した場合、カーネルは %rsp-128 にシグナルフレームを構築します。これにより、%rdi が指すメモリを上書きする可能性があります。 これが次の命令で UC_MCONTEXT_GREGS_RIP(%rdi) を読み出す前に発生すると、復元された命令ポインタが破損する可能性があります。私たちのクラッシュでは、それが NULL になりました。 それがバグです。 ## なぜコアダンプが通常の不良リターンとして隠蔽されていたのか このアセンブリは、私たちが混乱させた観察結果の一つも説明しています：なぜ関数 X の前のスタックフレームの戻りアドレススロットに NULL が含まれていたのかという点です。 setcontext は %rdi を含むすべてのレジスタを復元するように記述されているため、制御転送の最終段階で UC_MCONTEXT_GREGS_RIP(%rdi) を読み取るためにそのレジスタを使用することはできません。代わりに、値をより早く読み取り、それをスタックに保存し、さらにいくつかのレジスタを復元した後、retq 命令を使用して保存された値を読み取り、制御を転送します。 コアファイル上で「関数が NULL に戻った」と見えた現象は、実際には「アンワインダーがスタック上にターゲットの戻り先アドレスを合成したが、その転送が完了する前にターゲットが破損していた」ものでした。私たちは、戻り先アドレスのスロットに対する破損は必ずその場で起こるものだと仮定していました。なぜなら、（破損可能な）データを意図的に戻り先アドレスのスロットに書き込む場所が存在しないことを知らなかったからです。 A single-instruction race window このバグがどれほど不合理に見えるかは、この競合状態のウィンドウがいかに狭いかによって決まります。このような競合状態では、外部イベント（シグナル）が別のスレッドが行う 2 つのステップの間で発生する必要があります。その 2 つのステップが互いに近ければ近いほど、競合状態が発生する可能性は低くなります。 この場合、脆弱なウィンドウは文字通り 1 命令幅しかありません！シグナルは %rsp が変更された後に、次の命令が %rip を読み込む前に配信されなければなりません。現代のスーパースカラーアウト・オブ・オーダー CPU では、このような単純な命令を 1 サイクルあたり複数実行できるため、競合ウィンドウはおよそ 100 ピコ秒です。 この競合状態を発見したとき、私たちの最初の反応は、観測されたクラッシュ率を説明するには稀すぎてありえないというものでした。私たちは fleet 全体で 1 日に 12 件以上の戻り先 NULL クラッシュを検出していました。例外クリーンアップ中に 1 命令分の競合が本当にそのような頻度を引き起こすことができるのでしょうか？ フェルマー推定に頼りました。脆弱なウィンドウが 10 のマイナス 10 乗秒のオーダーであり、SIGUSR2 が CPU 時間の 10 のマイナス 2 乗秒ごとに到着すると仮定すれば、各例外クリーンアップハンドラまたは catch ブロックが競合に負ける確率はおよそ 10 のマイナス 8 乗となります。 Rockset では、内部のインジェストバックプレッシャー機構の一部として例外を使用しています。単一の過負荷ホストでは、1 秒あたり 10 の 4 乗個程度の例外をスローする可能性があります。これは、バックプレッシャーを使用しているホストにおける障害間の平均時間が 10 の 4 乗秒、つまり数時間に一度クラッシュすることを意味します。フリート規模全体で見れば、これは観測されたクラッシュ頻度を十分に説明するのに十分な量です。 ## なぜ今になって libunwind のバグが現れたのか？ GNU libunwind のバグは古く、18 年以上前に存在し、C++ 例外のアンワインディングをサポートした最初の x86_64 バージョンから含まれています。 では、なぜそれが今になって現れたのでしょうか？ クラッシュ率は、スローされる例外の数と配信されるシグナルの数にほぼ比例します。また、シグナルハンドラが消費するスタックの量にも依存しています。 Rockset はこれら 3 つの軸すべてにおいて特異です。通常の過負荷制御の一部として高頻度で例外をスローし、coarse_thread_cputime_clock のせいで SIGUSR2 を非常に頻繁に配信しており、さらに今年初めにマージされたシグナルを処理できるように timer_getoverrun 関数を呼び出すことで、SIGUSR2 ハンドラがより多くのスタックを使用するように変更しました。 その最後の修正は重要だったようです。ハンドラが使用するスタック量が十分に少なければ、古い ucontext_t メモリに到達して上書きするのを防げる可能性があります。この変更以前には、これらのクラッシュを全く観測していませんでした。変更後、クラッシュ発生率は低く維持されていましたが、バックプレッシャーメカニズムに負荷をかけるいくつかのユースケースで負荷を増加させたところ、状況が変わりました。 つまり、libunwind のバグは常に存在していたのですが、例外発生率、シグナル発生率、およびハンドラのスタック使用量の積が、運用上検出可能な閾値に達したのは最近のことだったのです。 このメカニズムは、ハードウェアのバグと libunwind のバグの両方が主に DocumentTree::updateDocument 内でクラッシュするという偶然の一致も説明しています。libunwind に起因するクラッシュはこのメソッドに強く偏っていました。なぜなら、インジェストバックプレッシャーを適用するために例外をスローする時点で、このメソッドは常にアクティブな状態にあるからです。また、%rsp のアライメントミスによるクラッシュも同様に強く選択されていました。その理由は、問題のあるハードウェアノードがバッチインジェストに使用される SKU であり、その CPU 時間の大部分をこのメソッドで消費しているためです。 私たちの即座の対策は、GNU libunwind から libgcc のアンワインダ（unwinder）へ切り替えることでした。これ自体も良好なトレードオフでした。libgcc の実装はロック競合を削減するための多くの作業によって改善されており、大規模な VM へのスケーリングにおいて重要な要素となっています。 また、自己完結型の再現手順と [修正(新しいウィンドウで開く)](https://github.com/libunwind/libunwind/commit/a9b9293b286c14b9ed19db501aa347b46edd8a28) を GNU libunwind にアップストリームし、他のアンワインダーには同様の問題がないことを確認しました。 ## 集団レベルでの診断の力 このデバッグの旅は、動的リンク、DWARF アンワインドメタデータ、Linux シグナル配信、System V ABI、および C++ 例外機構の詳細について多くの教訓を与えてくれました。しかし、最も重要な教訓はそれらよりも単純でした。 最も重要だったのは、巧妙なアセンブリコードの読み込みや詳細に関する深い知識ではありません。それは高品質なデータセットを構築することでした。このデータセットがなければ、私たちは2つの異なる現象を1つの物語に混ぜ合わせ、混乱から抜け出すために推論しようとしていました。正確で完全な集団データが揃ったことで、問題の構造は明白になりました：一方のクラッシュ集団は不良ホストに属し、もう一方は libunwind 内の競合状態に属していました。データが改善されるにつれて、デバッグも容易になりました。 Rockset のようなインフラストラクチャシステムにとって、これは非常に重要です。この調査は、詳細な計測、自動調査、および運用ツールの継続的な改善への当社のコミットメントを強化しました。信頼性は、バグが発生した後に修正するだけのことではありません。それは、不可能に見える問題を診断可能で解決可能な問題に変えるためのデータ、ワークフロー、そしてスキルを構築することなのです。

コアダンプ疫学：18 年前のバグを修正

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト