21.3. コアダンプを使用したアプリケーションのクラッシュの状態の検査

前提条件

  • コアダンプファイルおよび sosreport
  • GDB および elfutils がシステムにインストールされていること

手順

  1. クラッシュが発生した実行可能ファイルを特定するには、コアダンプファイルを指定して eu-unstrip コマンドを実行します。

    $ eu-unstrip -n --core=./core.9814
    0x400000+0x207000 2818b2009547f780a5639c904cded443e564973e@0x400284 /usr/bin/sleep /usr/lib/debug/bin/sleep.debug [exe]
    0x7fff26fff000+0x1000 1e2a683b7d877576970e4275d41a6aaec280795e@0x7fff26fff340 . - linux-vdso.so.1
    0x35e7e00000+0x3b6000 374add1ead31ccb449779bc7ee7877de3377e5ad@0x35e7e00280 /usr/lib64/libc-2.14.90.so /usr/lib/debug/lib64/libc-2.14.90.so.debug libc.so.6
    0x35e7a00000+0x224000 3ed9e61c2b7e707ce244816335776afa2ad0307d@0x35e7a001d8 /usr/lib64/ld-2.14.90.so /usr/lib/debug/lib64/ld-2.14.90.so.debug ld-linux-x86-64.so.2

    出力には、行ごとに各モジュールの詳細が、スペースで区切られて表示されます。情報は以下の順序で一覧表示されます。

    1. モジュールがマッピングされているメモリーアドレス
    2. モジュールのビルド ID、およびメモリー内の場所
    3. モジュールの実行可能ファイル名 - 不明の場合は -、モジュールがファイルから読み込まれていない場合は . と表示されます。
    4. デバッグ情報のソース - 使用可能な場合はファイル名が表示されます。実行可能ファイル自体に含まれている場合は .、存在しない場合は - と表示されます。
    5. 主要なモジュールの共有ライブラリー名 (soname) または [exe]

    この例では、重要な詳細は、テキスト [exe] を含む行のファイル名 /usr/bin/sleep と、ビルド ID 2818b2009547f780a5639c904cded443e564973e です。この情報を使用して、コアダンプの分析に必要な実行可能ファイルを特定できます。

  2. クラッシュした実行可能ファイルを取得します。

    • 可能であれば、クラッシュが発生したシステムからコピーします。コアファイルから抽出したファイル名を使用します。
    • または、お使いのシステムで同じ実行可能ファイルを使用します。Red Hat Enterprise Linux にビルドされた実行可能ファイルにはそれぞれ、固有の build-id 値を持つメモが含まれています。関連するローカルで利用可能な実行可能ファイルの build-id を判別します。

      $ eu-readelf -n executable_file

      この情報を使用して、リモートシステムの実行可能ファイルをローカルコピーと一致させます。ローカルファイルの build-id とコアダンプに記載されている build-id は一致する必要があります。

    • 最後に、アプリケーションが RPM パッケージからインストールされている場合は、パッケージから実行可能ファイルを取得できます。sosreport 出力を使用して、必要なパッケージの正確なバージョンを確認します。
  3. 実行可能ファイルで使用する共有ライブラリーを取得します。実行可能ファイルと同じ手順を使用します。
  4. アプリケーションがパッケージとして配布されている場合は、GDB で実行可能ファイルを読み込み、足りない debuginfo パッケージに関するヒントを表示します。詳細は、「GDB を使用したアプリケーションまたはライブラリー向けの debuginfo パッケージの取得」を参照してください。
  5. コアファイルの詳細を調べるには、GDB で実行可能ファイルとコアダンプファイルを読み込みます。

    $ gdb -e executable_file -c core_file

    不足しているファイルとデバッグ情報に関する追加のメッセージは、デバッグセッションで不足しているものを特定するのに役に立ちます。必要に応じて直前の手順に戻ります。

    アプリケーションのデバッグ情報がパッケージではなくファイルとして利用できる場合は、symbol-file コマンドを使用してこのファイルを GDB に読み込みます。

    (gdb) symbol-file program.debug

    program.debug は、実際のファイル名に置き換えます。

    注記

    コアダンプに含まれるすべての実行可能ファイルのデバッグ情報をインストールする必要はない場合があります。これらの実行可能ファイルのほとんどは、アプリケーションコードで使用されるライブラリーです。これらのライブラリーが分析中の問題の直接原因でない可能性があるので、ライブラリーのデバッグ情報を含める必要はありません。

  6. GDB コマンドを使用して、クラッシュした時点のアプリケーションの状態を検査します。「GDB を使用したアプリケーションの内部状態の検査」を参照してください。

    注記

    コアファイルを分析する場合に、GDB が実行中のプロセスに割り当てられる訳ではありません。実行を制御するコマンドは影響を受けません。

関連資料


このページには機械翻訳が使用されている場合があります (詳細はこちら)。