目次 前 次
17.4 コア・ダンプの収集
このセクションでは、コア・ダンプ(クラッシュ・ダンプとも呼ばれる)の生成および収集方法について説明します。コア・ダンプまたはクラッシュ・ダンプとは、実行中のプロセスのメモリー・スナップショットです。コア・ダンプは、致命的エラーまたは処理できないエラー(シグナルまたはシステム例外など)の発生時にオペレーティング・システムによって自動的に作成されることがあります。また、コア・ダンプはシステム提供のコマンド行ユーティリティによって強制されることもあります。ハングアップしているように見えるプロセスを診断する際にコア・ダンプが役立つ場合があります。つまり、コア・ダンプによってハングアップの原因に関する情報が明らかになることがあります。
コア・ダンプを収集する場合は、コア・ファイルを解析できるように、必ず環境に関するその他の情報(OSバージョン、パッチ情報、致命的エラー・ログなど)も収集してください。
コア・ダンプには通常、クラッシュまたはハング・アップしたプロセスのメモリー・ページがすべて含まれているとはかぎりません。ここで取り上げている各オペレーティング・システムでは、プロセスのテキスト(またはコード)ページはコア・ダンプに含まれません。ただし、便宜上、コア・ダンプは少なくともヒープとスタックのページで構成されている必要があります。クラッシュのポストモーテム解析には、切り詰められていない完全なコア・ダンプ・ファイルの収集が不可欠です。
次の項では、コア・ダンプの収集シナリオについて説明します。
17.4.1 Oracle Solarisでのコア・ダンプの収集
Oracle Solarisオペレーティング・システムでは、セグメンテーション違反や不正な命令などの処理できないシグナルによってコア・ダンプが作成されます。デフォルトでは、コア・ダンプはプロセスの現在の作業ディレクトリに作成され、コア・ダンプ・ファイルの名前はcoreになります。ユーザーは、コア・ファイル管理ユーティリティcoreadmを使用すると、そのコア・ダンプの場所と名前を構成できます。この手順については、coreadmユーティリティのマニュアル・ページに詳しく説明されています。
ulimitユーティリティは、現在のシェルとその子孫で利用できるシステム・リソースへの制限を設定または取得するために使用されます。コア・ファイルのサイズ制限をチェックまたは設定するには、ulimit -cコマンドを使用します。その制限が必ずunlimitedに設定されるようにしてください。そうしないと、コア・ファイルが切り詰められる可能性があります。
|
注: ulimitはBashシェルの組込みコマンドです。Cシェルでは、limitコマンドを使用してください。 |
VMまたはアプリケーションの起動に使用されるスクリプトがコア・ダンプの作成を無効にしないようにしてください。
gcoreユーティリティを使用すると、実行中のプロセスのコア・イメージを取得できます。このユーティリティは、コア・ダンプを強制的に作成させるプロセスのプロセスID (pid)を受け入れます。
マシン上で実行されているJavaプロセスのリストを取得するには、次のいずれかのコマンドを使用できます。
-
ps -ef | grep java -
pgrep java -
jps
|
注: jpsコマンド行ユーティリティでは、名前の照合(つまり、プロセスのコマンド名の中に「java」がないか検索する)を行わないため、Javaプロセスだけでなく、Java VMの埋込みプロセスも一覧表示できます。 |
次は、Oracle Solarisでコア・ダンプを収集するための2つの方法です。
-
Oracle SolarisでのShowMessageBoxOnErrorオプション:
Javaプロセスは、
-XX:+ShowMessageBoxOnErrorコマンド行オプションを使って起動できます。致命的エラーが発生すると、そのプロセスは標準エラーにメッセージを出力し、標準入力からの「yes」または「no」の応答を待ちます。例17-1は、予期しないシグナルが発生した場合の出力を示しています。例17-1 Solarisでの予期しないシグナル・エラー
======================================================================= Unexpected Error ----------------------------------------------------------------------- SIGSEGV (0xb) at pc=0xfeba31ac, pid=8677, tid=2 Do you want to debug the problem? To debug, run 'dbx - 8677'; then switch to thread 2 Enter 'yes' to launch dbx automatically (PATH must include dbx) Otherwise, press RETURN to abort... =======================================================================
「
yes」と応答するか、[Return]([Enter])キーを押す前に、gcoreユーティリティを使用してコア・ダンプを強制します。その後、「yes」と入力してdbxデバッガを起動できます。 -
trussユーティリティによるプロセスの中断:
-XX:+ShowMessageBoxOnErrorオプションを指定できない場合は、trussユーティリティを使用できる可能性があります。このOracle Solarisオペレーティング・システムのユーティリティは、システム・コールおよびシグナルをトレースするために使用されます。このユーティリティを使用すると、特定の関数またはシステム・コールに達した時点でプロセスを中断できます。例17-2のコマンドは、
trussユーティリティを使用して、exitシステム・コールが実行される(つまり、プロセスが終了しようとしている)ときにプロセスを中断する方法を示しています。プロセスが
exitを呼び出すと、そのプロセスが中断されます。この時点で、デバッガをプロセスに接続することも、gcoreを呼び出してコア・ダンプを強制することもできます。
17.4.2 Linuxでのコア・ダンプの収集
Linuxオペレーティング・システムでは、セグメンテーション違反や不正な命令などの処理できないシグナルによってコア・ダンプが作成されます。デフォルトでは、コア・ダンプはプロセスの現在の作業ディレクトリに作成され、コア・ダンプ・ファイルの名前はcore.pidになります(pidはクラッシュしたJavaプロセスのプロセスID)。
ulimitユーティリティは、現在のシェルとその子孫で利用できるシステム・リソースへの制限を設定または取得するために使用されます。コア・ファイルのサイズ制限をチェックまたは設定するには、ulimit -cコマンドを使用します。その制限が必ずunlimitedに設定されるようにしてください。そうしないと、コア・ファイルが切り詰められる可能性があります。
|
注: ulimitはBashシェルの組込みコマンドです。Cシェルでは、limitコマンドを使用してください。 |
VMまたはアプリケーションの起動に使用されるスクリプトがコア・ダンプの作成を無効にしないようにしてください。
gcoreコマンドをgdb (GNUデバッガ)インタフェースで使用すると、実行中のプロセスのコア・イメージを取得できます。このユーティリティは、コア・ダンプを強制的に作成させるプロセスのpidを受け入れます。
マシン上で実行されているJavaプロセスのリストを取得するには、次のいずれかのコマンドを使用できます。
-
ps -ef | grep java -
pgrep java -
jps
|
注: jpsコマンド行ユーティリティでは、名前の照合(つまり、プロセスのコマンド名の中に「java」がないか検索する)を行わないため、Javaプロセスだけでなく、Java VMの埋込みプロセスも一覧表示できます。 |
次は、Linuxでコア・ダンプを収集するための1つのオプションです。
-
LinuxでのShowMessageBoxOnErrorオプション:
Javaプロセスは、
-XX:+ShowMessageBoxOnErrorコマンド行オプションを使って起動できます。致命的エラーが発生すると、そのプロセスは標準エラーにメッセージを出力し、標準入力からの「yes」または「no」の応答を待ちます。例17-3は、予期しないシグナルが発生した場合の出力を示しています。例17-3 Linuxでの予期しないシグナル・エラー
======================================================================= Unexpected Error ----------------------------------------------------------------------- SIGSEGV (0xb) at pc=0x06232e5f, pid=11185, tid=8194 Do you want to debug the problem? To debug, run 'gdb /proc/11185/exe 11185'; then switch to thread 8194 Enter 'yes' to launch gdb automatically (PATH must include gdb) Otherwise, press RETURN to abort... =======================================================================
前述のエラー・レポートで示唆されているように、
gdb(GNUデバッガ)インタフェースを起動するには、「yes」と入力します。gdbプロンプトで、gcoreコマンドを指定できます。このコマンドは、デバッグされたプロセスのコア・ダンプをcore.pidという名前で作成します(pidはクラッシュしたプロセスのプロセスID)。使用しているgdbバージョンでgdb gcoreコマンドがサポートされていることを確認してください。gdbコマンド・プロンプトで、help gcoreを確認してください。
17.4.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.4.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つの方法です。
-
ワトソン博士の構成:
ワトソン博士のデバッガは、クラッシュ・ダンプ・ファイルの作成に使用されます。デフォルトでは、ワトソン博士のデバッガ(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に示されたコマンドを使用してクラッシュ・ダンプを取得できます。
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プロセスのワトソン博士のダンプを生成できます。このユーティリティは、プロセスがハングアップしているように見える場合にも使用できます。