コアダンプとクラッシュ解析の仕組み

コアダンプとは何の写しか

コアダンプは、プロセスが異常終了した瞬間の アドレス空間とCPU状態のスナップショット をファイルに固めたものです。デバッガでステップ実行できない本番障害でも、この一枚の死体写真があれば、どの命令で・どんなレジスタ値で・どんなコールスタックで死んだかを事後に剖検できます。再現しないクラッシュほどコアダンプの価値が高い、というのが実務の前提です。

「コア」という語は磁気コアメモリ時代の名残で、要するに メモリの内容そのもの を指します。何が写されるかは正確に決まっています。書き込み可能なデータ領域・ヒープ・スタック、つまり「失われると死因が分からなくなる可変状態」です。逆に、テキスト（コード）セグメントや読み込み専用のマップは原則ダンプに含めません。元の実行ファイルや共有ライブラリを読めば同じ内容が手に入るため、写す意味がないからです。

どのシグナルがコアを生むのか

コアダンプはシグナルのデフォルト動作の一種です。すべてのシグナルがコアを生むわけではなく、「プログラムの不変条件が壊れた」種類のシグナル だけがデフォルト動作 Core（終了＋コア生成）を持ちます。

ここで重要なのは、これらが 同期シグナル、すなわちCPUの例外（フォルト/トラップ）から生まれる点です。不正アクセスをハードウェアが検知してページフォルト例外を起こし、カーネルが「これは正規のページではない」と判断して当該プロセスへ SIGSEGV を送る——この配送経路は シグナル配送の内部とシグナルセーフティ の通りです。コア生成は、ハンドラが登録されておらずデフォルト動作が選ばれたときに、配送処理の中でカーネルが直接行います。

ELFコアファイルの構造

生成されるコアファイルは、実行ファイルと同じ ELF形式 です。ただしタイプは ET_EXEC や ET_DYN ではなく ET_CORE で、セクションヘッダを持たず プログラムヘッダ（セグメント）だけ で構成されます。ELFの基本構造は ELFバイナリのロードとリンカ・ローダの内部 と共通で、コアはその「ロードの逆向き」——メモリ像をELFに固める操作だと捉えると理解が早いです。

コアに現れるセグメントは大きく二種類です。

ET_CORE の構成:
  PT_NOTE  ……… 1個。プロセスのメタ状態を可変長ノートの並びで保持
       NT_PRSTATUS   各スレッドの汎用レジスタ・停止シグナル番号
       NT_PRPSINFO   プロセス名・PID・UID等の概要
       NT_FPREGSET   浮動小数点レジスタ
       NT_X86_XSTATE 拡張レジスタ状態（SSE/AVX等）
       NT_FILE       マップされたファイルとアドレス・オフセット対応表
  PT_LOAD  ……… 複数個。ダンプ対象の各メモリ領域の中身そのもの
       p_vaddr  …… その領域が本来あった仮想アドレス
       p_offset …… コアファイル内でのその領域の位置
       p_memsz  …… 領域サイズ
       p_flags  …… R/W/X 権限

PT_NOTE が「状態」、PT_LOAD が「中身」だと押さえれば十分です。デバッガは死亡時のレジスタを NT_PRSTATUS から取り出してプログラムカウンタとスタックポインタを復元し、PT_LOAD 群を仮想アドレス空間として再構成して、その上でスタックフレームを巻き戻します。マルチスレッドプロセスでは PT_NOTE 内に スレッド数だけ NT_PRSTATUS が並ぶ ため、全スレッドのバックトレースを取れます。

core_pattern：出力先とパイプハンドラ

コアの出力先と命名は kernel.core_pattern（/proc/sys/kernel/core_pattern）で決まります。%p（PID）、%e（実行ファイル名）、%s（シグナル番号）、%t（時刻）などのテンプレートでファイル名を組み立てます。素朴な設定はこうです。

/var/cores/core.%e.%p.%t

より強力なのが、先頭を |（パイプ）で始める書式です。この場合カーネルはファイルに書く代わりに、指定したプログラムを起動し、コアの中身をそのプロセスの標準入力へ直接ストリーム します。

|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h

クラッシュしたプロセス自身をデバッガで掴んで解析したい場合は、コアに頼らず生きたプロセスにアタッチする手もあります。その土台が ptraceとデバッガ・トレーサの仕組み で、gcore のように動作中プロセスへ ptrace でアタッチしてオンデマンドでコアを吐かせるツールもこの上に立っています。

ユーザー空間のクラッシュとカーネルパニックは別物

ここまではユーザー空間プロセスのコアダンプでした。プロセスが SIGSEGV で死んでも、カーネル自身は何も壊れていません。カーネルは例外を捕まえて該当プロセスにシグナルを送り、コアを書き、プロセスを回収するだけで、システム全体は動き続けます。

問題は カーネル自身が壊れたとき です。カーネル内のヌルポインタ参照やデータ構造の不整合（oops）が致命的だと判断されると panic() が呼ばれます。このときコアダンプの仕組みは使えません。死んだ当人であるカーネルが、自分のメモリを自分で安全に書き出すことは原理的にできないからです。信頼できる解析を行うには、壊れていない別のカーネル が必要になります。これを実現するのが kdump です。

kexec/kdump：カーネルクラッシュの解析

kdump の核心は kexec——通常のブートチェーン（ファームウェア・ブートローダ）を経由せず、動作中のカーネルから別のカーネルへ直接ジャンプ するブート機構です。BIOS/UEFIの再初期化を飛ばすため高速で、これが「壊れたカーネルから即座に解析カーネルへ切り替える」鍵になります。通常起動の文脈は ブートチェーンの内部（UEFI・ブートローダ・initramfs） を参照してください。

仕組みは「メモリの一部をあらかじめ囲っておく」点に尽きます。

平常時（システム起動直後）:
  crashkernel=512M で物理メモリの一区画を予約し、
  本番カーネルからは見えない領域として隔離しておく。
  その予約領域にクラッシュカーネル（解析用の第二カーネル）を
  ロード済みの状態で待機させる。

panic 発生時:
  1. 本番カーネルの panic 経路が kexec を呼ぶ
  2. 予約領域のクラッシュカーネルへCPUを直接ジャンプ
       → 壊れた本番カーネルのコードは一切使わない
  3. クラッシュカーネルは予約領域内だけで起動する
       → 本番カーネルが使っていた物理メモリは温存される
  4. 旧カーネルの物理メモリ全体を /proc/vmcore として読み出し、
     ファイル（vmcore）に退避してから通常再起動

肝は、クラッシュカーネルが 本番カーネルのメモリに一切手を付けず、隔離された予約領域だけで立ち上がることです。だからこそ、/proc/vmcore を通して 死亡時の本番カーネルの物理メモリ像をそのまま 取り出せます。vmcore も本質はELFコアの一種で、物理メモリの各区画が PT_LOAD として並びます。

退避された vmcore は crash ユーティリティ で解析します。crash は vmcore と、対応するカーネルのデバッグ情報（vmlinux ＋シンボル）を突き合わせ、bt（バックトレース）、ps、log（カーネルログバッファ＝dmesgの最後の様子）、スラブやページ構造の検査を提供します。ユーザー空間のコアを gdb で読むのと構図は同じで、「メモリ像」＋「シンボル」＝復元 という原理は両者で共通です。

まとめ

• コアダンプ は異常終了時のアドレス空間とCPU状態のスナップショット。Core をデフォルト動作に持つ同期シグナルが、ハンドラ未登録時にカーネルへコア生成を行わせる。ulimit -c・suid_dumpable・ハンドラ登録の三点がコア有無を左右する。
• コアは ET_CORE のELFで、PT_NOTE（レジスタ・プロセス情報）と PT_LOAD（メモリ領域の実体） から成る。コード・シンボルは含まないため、解析には元バイナリとデバッグ情報を併せて gdb に渡す。
• 出力先と書式は core_pattern が決め、| 先頭でコアをハンドラの標準入力へ直接ストリームして圧縮・転送・選別できる。
• ユーザー空間のクラッシュではカーネルは無傷だが、カーネルpanic ではコア機構が使えない。kexec/kdump が予約した crashkernel 領域の第二カーネルへ切り替え、旧カーネルの物理メモリを /proc/vmcore として退避し、crash ツールで解析する。

死因の入口である例外とシグナルは シグナル配送の内部とシグナルセーフティ、コアと対をなすバイナリ側の知識は ELFバイナリのロードとリンカ・ローダの内部 を合わせて読むと、生成から解析までが一本の線で繋がります。