印刷ビューの終了

HotSpot VM のトラブルシューティングガイド

印刷ビュー

ドキュメント情報

はじめに

1. 診断ツールおよびオプション

2. ツールの詳細な説明

3. メモリーリークのトラブルシューティング

4. システムクラッシュのトラブルシューティング

5. ハングアップまたはループしているプロセスのトラブルシューティング

6. シグナル処理と例外処理の統合

7. バグレポートの提出

7.1 更新リリースに含まれる既存の修正のチェック

7.2 バグレポートの提出の準備

7.3 バグレポート用のデータの収集

7.3.1 ハードウェアの詳細

7.3.2 オペレーティングシステム

7.3.3 JDK バージョン

7.3.4 コマンド行オプション

7.3.5 環境変数

7.3.6 致命的エラーログ

7.3.7 コアダンプまたはクラッシュダンプ

7.3.8 問題の詳細な説明

7.3.9 ログおよびトレース

7.3.10 トラブルシューティング手順からの結果

7.4 コアダンプの収集

7.4.1 Solaris OS でのコアダンプの収集

7.4.1.1 Solaris OS での ShowMessageBoxOnError オプションの使用

7.4.1.2 truss を使用したプロセスの中断

7.4.2 Linux でのコアダンプの収集

7.4.2.1 Linux での ShowMessageBoxOnError オプションの使用

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

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

7.4.4.1 ワトソン博士の構成

7.4.4.2 クラッシュダンプの強制

A. 環境変数とシステムプロパティー

B. コマンド行オプション

C. 致命的エラーログ

D. このリリースのツールのサマリー

第 7 章

バグレポートの提出

この章では、バグレポートの提出方法に関する指針を提供します。これには、レポートを提出する前に試すこと、およびレポート用に収集するデータに関する提案が含まれています。

7.1 更新リリースに含まれる既存の修正のチェック

最新バージョンは JDK 7 です。このリリースへの定期的にスケジュールされた更新には、そのプラットフォームの初期リリース以降に確認された一連のクリティカルなバグの修正が含まれています。更新リリースが利用可能になると、Java SE ダウンロードサイトにあるデフォルトのダウンロードになります。

このダウンロードサイトには、そのリリースにおけるバグ修正のリストを示すリリースノートが含まれています。リストにある各バグは、バグデータベース内のバグの説明にリンクされています。リリースノートには、以前の更新リリースにおける修正のリストも含まれています。問題が発生した場合やバグの疑いがある場合には、診断の初期段階として、最新の更新リリースで使用可能な修正のリストをチェックしてください。

ある問題が、すでに修正されたバグと同じものであるか明確でない場合があります。そのため、可能であれば、最新の更新リリースでテストして、その問題が引き続き発生するかどうかを確認してください。

7.2 バグレポートの提出の準備

バグレポートを提出する前に、次の推奨事項を検討してください。

バグを提出する前に、問題が発生した環境が、サポートされている構成であることを確認します。サポート対象のシステム構成のサイトを参照してください。

システム構成のほかに、サポート対象のロケールのリストも確認します。サポート対象のロケールの Web ページを参照してください。

Solaris オペレーティングシステムの場合は、そのオペレーティングシステム用の推奨パッチクラスタを調べて、推奨パッチがインストールされていることを確認します。

7.3 バグレポート用のデータの収集

通常、バグレポートを作成したり、サポートコールを提出したりする場合は、できるだけ多くの関連データを収集することをお勧めします。このセクションでは、収集すべきデータを提案し、該当する場合は、データを取得するためのコマンドや一般的な手順に関する推奨事項を提供します。

バグレポートを提出する前に、次のデータを収集できます。

以降のセクションでは、各データについて種類別にさらに詳しく説明します。

7.3.1 ハードウェアの詳細

特定のハードウェア構成でのみバグが発生したり再現できたりすることがあります。致命的なエラーが発生した場合は、エラーログにハードウェアの詳細が含まれている可能性があります。エラーログを入手できない場合は、マシンのプロセッサの番号と種類、クロック速度、および該当する場合かつ既知の場合は、そのプロセッサの機能に関するいくつかの詳細をバグレポートにまとめます。たとえば Intel プロセッサの場合、ハイパースレッディングが使用可能であることがそれに該当します。

7.3.2 オペレーティングシステム

Solaris オペレーティングシステムでは、showrev -a コマンドはオペレーティングシステムのバージョンおよびパッチ情報を出力します。

Linux では、使用されているディストリビューションとバージョンを知ることが重要です。/etc/*release ファイルがリリース情報を示している場合がありますが、コンポーネントとパッケージは個別にアップグレードできるため、必ずしもそれが信頼できる構成を示しているとは限りません。そのため、*release ファイルからの情報に加えて、次の情報も収集してください。

7.3.3 JDK バージョン

JDK のバージョン文字列は、java -version コマンドを使用して取得できます。

同じマシン上に JDK のバージョンが複数インストールされている可能性があります。したがって、適切なバージョンの java コマンドが間違いなく使用されるように、そのインストールの bin ディレクトリが PATH 環境変数内でほかのインストールよりも前にあることを確認してください。

7.3.4 コマンド行オプション

バグレポートに致命的エラーログが含まれていない場合は、コマンド行全体とそのすべてのオプションを文書化することが重要です。これには、ヒープ設定を指定するオプション (-mx オプションなど) や HotSpot 固有のオプションを指定する -XX オプションが含まれます。

JDK の機能の 1 つに、ガベージコレクタエルゴノミクスがあります。サーバークラスマシンでは、java コマンドは HotSpot Server VM とパラレルガベージコレクタを起動します。マシンがサーバーマシンと見なされるのは、少なくとも 2 基のプロセッサと 2G バイト以上のメモリーを備えている場合です。

-XX:+PrintCommandLineFlags オプションを使用すると、コマンド行オプションを検証できます。このオプションは、コマンド行の VM に対するすべてのフラグを出力します。jmap ユーティリティーを使用すると、実行中の VM またはコアファイルのコマンド行オプションを取得することもできます。

7.3.5 環境変数

環境変数の設定が原因で問題が発生する場合があります。バグレポートの作成時に、次の Java 環境変数の値 (設定されている場合) を記入してください。

また、次のオペレーティングシステム固有の環境変数も収集してください。

7.3.6 致命的エラーログ

致命的エラーが発生すると、エラーログが作成されます。このファイルの詳細は、付録 C「致命的エラーログ」を参照してください。

このエラーログには、致命的エラーの発生時に得られた多くの情報 (バージョンや環境の情報、クラッシュを引き起こしたスレッドの詳細など) が含まれています。

致命的エラーログが生成される場合は、必ずそれをバグレポートやサポートコールに含めてください。

7.3.7 コアダンプまたはクラッシュダンプ

コアダンプやクラッシュダンプは、システムクラッシュまたはハングアッププロセスの診断を試みる際に非常に役立つ可能性があります。ダンプの生成手順は、「7.4 コアダンプの収集」で説明されています。

7.3.8 問題の詳細な説明

問題の説明を作成するときは、できるだけ多くの関連情報を含めるようにしてください。アプリケーション、環境、そして何よりも問題が発生した時間につながるイベントを記述します。

複雑なアプリケーション環境でしか問題を再現できない場合があります。その場合は、ログ、コアファイル、およびその他の関連情報を伴う説明が問題を診断する唯一の手段になる可能性があります。このような状況では、提出者が問題の発生しているシステムでさらなる診断を行なったり、テストバイナリを実行したりする意志があるかどうかをその説明で示すようにしてください。

7.3.9 ログおよびトレース

場合によっては、ログまたはトレース出力が問題の原因を迅速に特定するのに役立つ可能性があります。

たとえば、パフォーマンスの問題の場合、-verbose:gc オプションの出力が問題の診断に役立つ可能性があります。(これは、ガベージコレクタからの出力を有効にするオプションです。)

別のケースでは、jstat コマンドからの出力を使用すると、問題の発生に至るまでの期間にわたる統計情報を取得できます。

VM のデッドロックまたはハングアップ (ループが原因など) の場合は、スレッドスタックが問題の診断に役立つ可能性があります。スレッドスタックを取得するには、Ctrl + \ (Solaris OS と Linux の場合) および Ctrl + Break (Windows オペレーティングシステムの場合) を使用します。

通常は、関連のあるすべてのログ、トレース、およびその他の出力をバグレポートまたはサポートコールに含めます。

7.3.10 トラブルシューティング手順からの結果

バグレポートを提出する前に、必ず、実行したトラブルシューティング手順をすべて文書化してください。

たとえば、問題がクラッシュであり、アプリケーションにネイティブライブラリが含まれている場合は、バグがネイティブコード内にある可能性を減らすために、すでに -Xcheck:jni オプションを使ってアプリケーションを実行している場合があります。別のケースとして、HotSpot Server VM (-server オプション) で発生するクラッシュが考えられます。HotSpot Client VM (-client オプション) でもテストを行い、問題が発生しない場合は、バグが HotSpot Server VM に固有のものである可能性があることの目安になります。

一般に、すでに行われたトラブルシューティング手順と結果をすべてバグレポートに含めます。この種の情報によって、問題の診断に要する時間が短縮されることが頻繁にあります。

7.4 コアダンプの収集

このセクションでは、コアダンプ (クラッシュダンプとも呼ばれる) の生成と収集の方法について説明します。コアダンプまたはクラッシュダンプとは、実行中のプロセスのメモリースナップショットのことです。コアダンプは、致命的エラーまたは処理できないエラー (シグナルまたはシステム例外など) の発生時にオペレーティングシステムによって自動的に作成されることがあります。あるいは、システム提供のコマンド行ユーティリティーを使って強制的にコアダンプを作成することもできます。ハングアップしているように見えるプロセスを診断する際にコアダンプが役立つ場合があります。つまり、そのコアダンプによってハングアップの原因に関する情報が明らかになる可能性があります。

コアダンプを収集する場合は、コアファイルを解析できるように、必ず環境に関するその他の情報 (OS バージョン、パッチ情報、致命的エラーログなど) も収集してください。

コアダンプには通常、クラッシュまたはハングアップしたプロセスのメモリーページがすべて含まれているとはかぎりません。ここで取り上げている各オペレーティングシステムでは、プロセスのテキスト (またはコード) ページはコアダンプに含まれません。ただし、便宜上、コアダンプは少なくともヒープとスタックのページで構成されている必要があります。クラッシュのポストモーテム解析には、切り詰められていない完全なコアダンプファイルの収集が不可欠です。

7.4.1 Solaris OS でのコアダンプの収集

Solaris オペレーティングシステムでは、セグメンテーション違反や不正な命令などの処理できないシグナルによってコアダンプが作成されます。デフォルトでは、コアダンプはプロセスの現在の作業ディレクトリに作成され、コアダンプファイルの名前は core になります。ユーザーは、コアファイル管理ユーティリティー coreadm を使用すると、そのコアダンプの場所と名前を構成できます。この手順については、coreadm ユーティリティーのマニュアルページに詳しく説明されています。

ulimit ユーティリティーは、現在のシェルとその子孫が利用できるシステムリソースへの制限を取得または設定するために使用されます。コアファイルのサイズ制限をチェックまたは設定するには、ulimit -c コマンドを使用します。必ずこの制限を unlimited に設定してください。それ以外の場合、コアファイルが切り詰められる可能性があります。ulimit は Bash シェルの組み込みコマンドです。C シェルでは limit コマンドを使用します。

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

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

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

7.4.1.1 Solaris OS での ShowMessageBoxOnError オプションの使用

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

=======================================================================
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 キーを押す前に、gcore ユーティリティーを使用してコアダンプを強制します。その後、「yes」と入力して dbx デバッガを起動できます。

7.4.1.2 truss を使用したプロセスの中断

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

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

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

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

7.4.2 Linux でのコアダンプの収集

Linux オペレーティングシステムでは、セグメンテーション違反や不正な命令などの処理できないシグナルによってコアダンプが作成されます。デフォルトでは、コアダンプはプロセスの現在の作業ディレクトリに作成され、コアダンプファイルの名前は core.pid になります。ここで、pid はクラッシュした Java プロセスのプロセス ID です。

ulimit ユーティリティーは、現在のシェルとその子孫が利用できるシステムリソースへの制限を取得または設定するために使用されます。コアファイルのサイズ制限をチェックまたは設定するには、ulimit -c コマンドを使用します。必ずこの制限を unlimited に設定してください。それ以外の場合、コアファイルが切り詰められる可能性があります。ulimit は Bash シェルの組み込みコマンドです。C シェルでは limit コマンドを使用します。

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

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

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

7.4.2.1 Linux での ShowMessageBoxOnError オプションの使用

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

=======================================================================
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...
=======================================================================

上記のエラーレポートで提案されているように、「yes」と入力して gdb (GNU デバッガ) インタフェースを起動します。gdb プロンプトで、gcore コマンドを指定できます。このコマンドは、デバッグ対象のプロセスのコアダンプを core.pid という名前で作成します。ここで、pid はクラッシュしたプロセスのプロセス ID です。必ず gdb gcore コマンドが、使用しているバージョンの gdb でサポートされていることを確認してください。gdb コマンドプロンプトで help gcore を検索します。

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

次のリストでは、コアファイルが生成されない可能性がある主な理由について説明します。特に断りがないかぎり、このリストは Solaris OS と Linux の両方に関連します。

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

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

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

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

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

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

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

7.4.4.1 ワトソン博士の構成

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

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

drwtsn32 -i

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

drwtsn32

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

レジストリを使用すると、フルダンプを作成するようにワトソン博士を構成できます。レジストリキーは次のとおりです。

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

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

7.4.4.2 クラッシュダンプの強制

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

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

デバッガが接続されたら、次のコマンドを使用してクラッシュダンプを取得できます。

.dump /f crash.dmp

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

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

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

Solaris OS や Linux と同様に、Windows でも -XX:+ShowMessageBoxOnError コマンド行オプションを使用できます。致命的エラーが発生すると、プロセスはメッセージボックスを表示し、ユーザーからの「はい」または「いいえ」の応答を待ちます。

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