17.5 コア・ダンプの収集

17.5.1 Oracle Solarisでのコア・ダンプの収集

デフォルトでは、コア・ダンプはプロセスの現在の作業ディレクトリに作成されます。 コア・ダンプ・ファイルの名前はcoreです。 ユーザーは、コア・ファイル管理ユーティリティcoreadmを使用すると、そのコア・ダンプの場所と名前を構成できます。 この手順については、coreadmユーティリティのマニュアル・ページに詳しく説明されています。

ulimitユーティリティは、現在のシェルとその子孫で利用できるシステム・リソースへの制限を設定または取得するために使用されます。 コア・ファイルのサイズ制限をチェックまたは設定するには、ulimit -cコマンドを使用します。 制限がunlimitedに設定されていることを確認します。設定されていない場合、コア・ファイルは切り捨てられるか生成されない可能性があります。

VMまたはアプリケーションの起動に使用されるスクリプトがコア・ダンプの作成を無効にしないようにしてください。

gcoreユーティリティを使用すると、実行中のプロセスのコア・イメージを取得できます。 このユーティリティは、コア・ダンプを強制的に作成させるプロセスのプロセスID (pid)を受け入れます。

マシン上で実行されているJavaプロセスのリストを取得するには、次のいずれかのコマンドを使用できます。

• ps -ef | grep java

• pgrep java

• jcmd

次は、Oracle Solarisでコア・ダンプを収集するための2つの方法です。

• Oracle SolarisでのShowMessageBoxOnErrorオプション:

  Javaプロセスは、-XX:+ShowMessageBoxOnErrorコマンド行オプションを使って起動できます。 致命的エラーが発生すると、そのプロセスは標準エラーにメッセージを出力し、標準入力からの「yes」または「no」の応答を待ちます。

• trussユーティリティによるプロセスの中断:

  -XX:+ShowMessageBoxOnErrorオプションを指定できない場合は、trussユーティリティを使用できる可能性があります。 このOracle Solarisオペレーティング・システムのユーティリティは、システム・コールおよびシグナルをトレースするために使用されます。 このユーティリティを使用すると、特定の関数またはシステム・コールに達した時点でプロセスを中断できます。

  例17-2のコマンドは、trussユーティリティを使用して、exitシステム・コールが実行される(つまり、プロセスが終了しようとしている)ときにプロセスを中断する方法を示しています。

  例17-2 trussユーティリティによるプロセスの中断

  $ truss -t \!all -s \!all -T exit -p pid
  

  プロセスがexitを呼び出すと、そのプロセスが中断されます。 この時点で、デバッガをプロセスに接続することも、gcoreを呼び出してコア・ダンプを強制することもできます。

17.5.2 Linuxでのコア・ダンプの収集

デフォルトでは、コア・ダンプはプロセスの現在の作業ディレクトリに作成されます。 コア・ダンプ・ファイルの名前はcore.pidで、pidはクラッシュしたJavaプロセスのプロセスIDです。

すべてのシステムがコア・ファイルの作成を許可するように構成されているわけではありません。 ulimitユーティリティは、現在のシェルとその子孫で利用できるシステム・リソースへの制限を設定または取得するために使用されます。 コア・ファイルのサイズ制限をチェックまたは設定するには、ulimit -cコマンドを使用します。 制限がunlimitedに設定されていることを確認します。設定されていない場合、コア・ファイルは切り捨てられるか生成されない可能性があります。

VMまたはアプリケーションの起動に使用されるスクリプトがコア・ダンプの作成を無効にしないようにしてください。

gcoreコマンドをgdb (GNUデバッガ)インタフェースで使用すると、実行中のプロセスのコア・イメージを取得できます。 このユーティリティは、コア・ダンプを強制的に作成させるプロセスのpidを受け入れます。

マシン上で実行されているJavaプロセスのリストを取得するには、次のいずれかのコマンドを使用できます。

• ps -ef | grep java

• pgrep java

• jcmd

ShowMessageBoxOnErrorオプションを使用して、Linuxでコア・ダンプを収集できます。 -XX:+ShowMessageBoxOnErrorコマンドライン・オプションを使用してJavaプロセスを起動します。 致命的なエラーが発生すると、プロセスはメッセージを標準エラーに出力し、標準入力からのyesまたはnoレスポンスを待機します。

17.5.3 コア・ファイルを取得しない理由

次のリストでは、コア・ファイルが生成されない可能性がある主な理由について説明します。 特に断りがないかぎり、このリストはOracle SolarisとLinuxオペレーティング・システムの両方に関連します。

• 現在のユーザーに、そのプロセスの現在の作業ディレクトリへの書込み権がありません。

• 現在のユーザーには現在の作業ディレクトリへの書込み権がありますが、読取り専用の権限を持つcoreという名前のファイルがすでに存在しています。

• 現在のディレクトリに十分な空き領域がないか、空き領域がまったく残っていません。

• 現在のディレクトリに、coreという名前のサブディレクトリがあります。

• 現在の作業ディレクトリがリモートです。 NFS (Network File System)によってマップされている可能性があり、ちょうどコア・ダンプが作成されようとしているときにNFSが失敗しました。

• Oracle Solarisオペレーティング・システムのみ: coreadmツールを使用してコア・ファイルのディレクトリと名前が構成されましたが、構成されたディレクトリまたはファイル名に前述のいずれかの理由が当てはまります。

• コア・ファイルのサイズ制限が低すぎます。 ulimit -cコマンド(Bashシェル)またはlimit -cコマンド(Cシェル)を使用して、コア・ファイルの制限をチェックしてください。 このコマンドからの出力がunlimitedでない場合、コア・ダンプのファイル・サイズが十分な大きさでない可能性があります。 その場合は、切り詰められたコア・ダンプを受け取るか、コア・ダンプをまったく受け取りません。 また、VMまたはアプリケーションの起動に使用されるスクリプトがコア・ダンプの作成を無効にしないようにしてください。

• プロセスがsetuidプログラムを実行しているため、オペレーティング・システムは、明示的に構成されないかぎり、コアをダンプしません。

• Java固有: プロセスがSIGSEGVまたはSIGILLを受信してもコアがダンプされなかった場合、プロセスがそれを処理した可能性があります。 たとえば、HotSpot VMはSIGSEGVシグナルを、正当な目的(NullPointerExceptionのスローや最適化解除など)のために使用します。 Java VMによってシグナルが処理されないのは、現在の命令(PC)がJava VM生成コードから外れる場合だけです。 これらが、HotSpotでコアがダンプされる唯一の場合になります。

• Java固有: VMの作成に、JNI呼び出しAPIが使用されました。 標準のJavaランチャは使用されませんでした。 カスタムJavaランチャ・プログラムが、シグナルをただ消費するだけでその処理をすませ、ログ・エントリを暗黙のうちに生成しました。 この状況は、特定のアプリケーション・サーバーやWebサーバーで発生しました。 これらのJava VM埋め込みプログラムは、異常終了後にシステムの再起動(フェイルオーバー)を透過的に試行します。 この場合、コア・ダンプが生成されないという事実は、機能であってバグではありません。

17.5.4 Windowsでのクラッシュ・ダンプの収集

Windowsオペレーティング・システムには、3種類のクラッシュ・ダンプがあります。

• ワトソン博士のログ・ファイル。これは、障害時のスタック・トレースとその他のいくつかの詳細を含むテキスト・エラー・ログ・ファイルです。

• ユーザーのミニダンプ。これは「部分的な」コア・ダンプと見なすことができます。 このダンプにはプロセスの有用なメモリー・ページがすべて含まれているわけではないため、完全なコア・ダンプではありません。

• ワトソン博士の完全ダンプ。これは、Unixコア・ダンプと同等のものです。 このダンプには、プロセスのほとんどのメモリー・ページが含まれています(コード・ページを除く)。

Windowsで予期しない例外が発生した場合、実行されるアクションは次のレジストリ・キーの2つの値によって異なります。

\\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug

それらの2つの値には、DebuggerおよびAutoという名前が付いています。 Auto値は、アプリケーション・エラーが発生したときに、Debuggerエントリの値で指定されたデバッガが自動的に起動するかどうかを示します。

• Auto値が0の場合は、アプリケーション・エラーが発生したときにシステムがメッセージ・ボックスを表示してユーザーに知らせることを示します。

• Auto値が1の場合は、デバッガが自動的に起動することを示します。

Debuggerの値は、プログラム・エラーのデバッグに使用されるデバッガ・コマンドです。

Windowsでは、プログラム・エラーが発生すると、Auto値を調べて、その値が0の場合に、Debugger値に含まれるコマンドを実行します。 Debuggerの値が有効なコマンドである場合は、「OK」と「キャンセル」の2つのボタンを含むメッセージ・ボックスが作成されます。 ユーザーが「OK」をクリックすると、プログラムが終了します。 ユーザーが「キャンセル」をクリックすると、指定されたデバッガが開始されます。 Autoエントリの値が1に設定され、Debuggerエントリの値が有効なデバッガを表すコマンドを指定している場合、システムはそのデバッガを自動的に起動し、メッセージ・ボックスを生成しません。

次は、Windowsでクラッシュ・ダンプを収集するための2つの方法です。

• Dr. Watsonの構成:

  ワトソン博士のデバッガは、クラッシュ・ダンプ・ファイルの作成に使用されます。 デフォルトでは、ワトソン博士のデバッガ(drwtsn32.exe)はWindowsシステム・フォルダ(%SystemRoot%\System32)にインストールされます。

  ワトソン博士をポストモーテム・デバッガとしてインストールするには、次のコマンドを実行します。

  drwtsn32 -i
  

  クラッシュ・ダンプ・ファイルの名前と場所を構成するには、オプションを付けずにdrwtsn32を実行します。

  ワトソン博士のGUIウィンドウで、「クラッシュ・ダンプ・ファイルの作成」チェックボックスが選択されていること、およびクラッシュ・ダンプ・ファイル・パスとログ・ファイル・パスがそれぞれのテキスト・フィールドに構成されていることを確認します。

  レジストリを使用すると、フル・ダンプを作成するようにワトソン博士を構成できます。 例17-4に、レジストリ・キーを示します。

  例17-4 フル・ダンプを作成するレジストリ・キー

  System Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DrWatson]
  Entry Name: CreateCrashDump
  Value: (0 = disabled, 1 = enabled)
  

  ノート: アプリケーションが例外を処理する場合は、レジストリで構成されたデバッガは呼び出されません。 その場合は、-XX:+ShowMessageBoxOnErrorコマンド行オプションを使用することで、致命的エラーの状態ではユーザーが介入するまで待つようにプロセスを強制するのが適切である可能性があります。

• クラッシュ・ダンプの強制:

  Windowsオペレーティング・システムでは、userdumpコマンド行ユーティリティを使って実行中のプロセスのDr. Watsonダンプを強制できます。 userdumpユーティリティはWindowsには付属せず、代わりにOEM Support Toolsパッケージのコンポーネントとしてリリースされています。

  クラッシュ・ダンプを強制する別の方法は、windbgデバッガを使用することです。 windbgを使用することの主な利点は、非侵入的な方法(つまり読取り専用)でプロセスに接続できることです。 通常、Windowsはクラッシュ・ダンプの取得後にプロセスを終了させますが、非侵入型の接続ではクラッシュ・ダンプの取得後もプロセスを続行できます。 デバッガを非侵入的に接続するには、「Attach to Process」オプションを選択し、「Noninvasive」チェックボックスにチェック・マークを付けます。

  デバッガが接続されたら、例17-5に示されたコマンドを使用してクラッシュ・ダンプを取得できます。

  例17-5 クラッシュ・ダンプの取得

  .dump /f crash.dmp
  

  windbgデバッガは、「Debugging Tools for Windows」のダウンロードに含まれています。

  このダウンロードに含まれる追加のdumpchk.exeユーティリティは、メモリー・ダンプ・ファイルが正しく作成されたことを検証できます。

  userdump.exeとwindbgのどちらにも、プロセスのpidが必要です。 userdump -pコマンドは、すべてのプロセスのプロセスとプログラムを一覧表示します。 これは、アプリケーションがjava.exeランチャで起動されることがわかっている場合に役立ちます。 ただし、カスタム・ランチャが使用される場合(埋め込みVM)、プロセスの認識が困難である可能性があります。 その場合は、Javaプロセスのpidのみを一覧表示するjpsコマンド行ユーティリティを使用できます。

  Oracle SolarisおよびLinuxオペレーティング・システムと同様に、Windowsでも-XX:+ShowMessageBoxOnErrorコマンド行オプションを使用できます。 致命的エラーが発生すると、プロセスはメッセージ・ボックスを表示し、ユーザーからのyesまたはnoの応答を待ちます。

  「はい」または「いいえ」をクリックする前に、userdump.exeユーティリティを使用して、そのJavaプロセスのワトソン博士のダンプを生成できます。 このユーティリティは、プロセスがハングアップしているように見える場合にも使用できます。