|
|
Oracle プロセスが突然クラッシュすると、Oracle JRockit JVM によってスナップショット、つまりクラッシュ ファイルが作成されます。クラッシュ ファイルにはコンピュータの状態と、クラッシュ時の JVM プロセスが記録されます。これらのクラッシュ ファイルはディスクに書き込まれ、プラットフォームおよびファイルに記録される情報の種類に応じて少しずつ異なる名前が付けられます (図 31-1 を参照)。
クラッシュ ファイルに含まれる情報の一部を使用して、JVM がクラッシュする原因となった問題の性質を判断することができます。クラッシュ ファイルに書かれている情報は、JRockit JVM のサポート組織が JVM の問題を解決するためにも非常に重要です。Oracle のサポート組織に問題を報告するときには、これらのクラッシュ ファイルを提示する必要があります (詳細については「Oracle サポートへのトラブル レポートの送付」を参照してください)。
この節では、各クラッシュファイルの違いと、それらを有効または無効にする方法について説明します。また、クラッシュ ファイルと診断の例を示し、クラッシュ ファイル内のテキストの情報を解釈する方法を説明します。この説明を読めば、Java アプリケーションを修復する方法や、JRockit JVM を使用、設定する方法を見つけられるようになります。
JRockit JVM がクラッシュすると、「ダンプ」と呼ばれるテキスト クラッシュ ファイルと、「mdmp」(windows プラットフォームでは minidump) または「コア」(Linux と Sun のプラットフォームではコア ファイル) と呼ばれるバイナリ クラッシュファイルの 2 種類のクラッシュ ファイルが作成されます (図 31-1 を参照)。この 2 種類のクラッシュ ファイルの形式は jrockit.<pid>.dump および jrockit.<pid>.mdmp/core で、pid には jrockit.<72>.dump のようにプロセス ID が数値で入ります。
テキスト dump ファイルには、クラッシュした時点での JVM に関する情報が記録されます。この情報から JVM クラッシュが発生した原因についてのヒントを得て、特定することができます。テキスト Dump ファイルに記録される情報の例をコード リスト 31-1 からコード リスト 31-4 に示します。テキスト dump ファイルは普通のテキスト エディタで表示することができます。テキスト dump ファイルの作成を無効にする方法については、「テキスト dump ファイルの無効化」を参照してください。
バイナリ core または mdmp クラッシュ ファイルには、JRockit JVM の全プロセスに関する情報が記録されます。このファイルはデバッガで開く必要があります。通常、バイナリ クラッシュ ファイルはサイズが非常に大きいので、ファイル全体をディスクに書き込むための十分なディスク領域があることを確認する必要があります。デフォルトでは、完全なバイナリ クラッシュ ファイルが記録されます。バイナリ クラッシュ ファイルのサイズを設定する方法については、「バイナリ クラッシュ ファイルのサイズ変更」を参照してください。バイナリ クラッシュ ファイルの作成を無効にする方法については、「バイナリ クラッシュ ファイルの無効化」を参照してください。
バイナリ core または mdmp クラッシュ ファイルのサイズは、大きく変化します。テキスト dump ファイルは通常 100KB 以下と非常に小さいのですが、バイナリ クラッシュ ファイルの方は、JRockit JVM の全プロセスのログを記録するようにデフォルトで設定されるため非常に大きくなり (図 31-2 を参照)、システムにかなりの記憶容量が必要になります。
クラッシュ ファイル サイズを設定するには、コマンド ライン オプション -XXdumpSize を使用します。デフォルトでこれが -XXdumpSize:large に設定されます。large に設定されたダンプには、Java ヒープを含む JVM プロセス全体が含まれます。small や normal を設定することもできますが、これらのサイズは、Java ヒープが除外されるため、JVM クラッシュのトラブルシューティングには十分ではありません。
バイナリ クラッシュ ファイルを使用しない場合は、-XXdumpSize:none に設定できます。このオプションの詳細については、Oracle JRockit JVM コマンド ライン リファレンスの「-XXdumpSize」を参照してください。
| 注意 : | Oracle JRockit のサポート組織に問題を報告する際には、必ず <Large> のバイナリ core または mdmp クラッシュ ファイルを送付する必要があります。 |
クラッシュ ファイルが書き込まれるディスク上に、バイナリ クラッシュ ファイル全体を書き込むのに十分なメモリがない場合、ファイルは可能な限り (つまり、ディスクが一杯になるまで) 大きくなります。
バイナリ クラッシュ ファイルおよびテキスト dump ファイルは両方とも現在の作業ディレクトリに保存されます (「Linux および Sun Solaris 上でのバイナリ core クラッシュ ファイルの有効化」を参照)。別の場所にクラッシュ ファイルを保存する場合は、JROCKIT_DUMP_PATH 環境変数を使って情報を格納する場所を指定します。既存の書き込み可能な場所を指定しなければなりません。
Linux や Sun Solaris システムの場合は、ulimit -c <value> をゼロよりも大きな値 (ulimit -c unlimited など) に設定します。この値はブロック単位で測定されます。各ブロックは 1KB に相当します。コマンドラインからでも、シェル スクリプトからでも値を設定できます。Linux や Solaris でクラッシュ ファイルを無効にするには、ulimit -c 0 を設定します。
バイナリ core クラッシュ ファイルを保存する場所を指定するには、次のように入力します。
export JROCKIT_DUMP_PATH=<ディレクトリのパス>
Windows 上では、常にバイナリ mdmp ファイルが作成されます。JROCKIT_DUMP_PATH 変数を指定しなければ、クラッシュ ファイルはカレント ディレクトリ (BEA JRockit を起動したディレクトリ) に保存されます。
クラッシュ ファイルを保存する場所を指定するには、次のように入力します。
set JROCKIT_DUMP_PATH=<ディレクトリのパス>
クラッシュ ファイルはデフォルトで有効になっているため、ユーザおよび JRockit JVM のプロセスに関するできるだけ多くの情報がクラッシュ時に必ず作成されます。しかし、ディスク領域が限られるなど、JVM でクラッシュ ファイルを何も作成したくない場合もあるかもしれません。
しかし、テキスト dump ファイルは小さいながらも、JVM に何が起きたのかを大まかに把握するための良い情報源となります。また、バイナリ core または mdmp クラッシュ ファイルは Oracle JRockit のサポート組織に問題を報告する際に必ず必要です。これらのことを、クラッシュ ファイルの作成を無効にする前によく考えてみてください。
テキスト dump ファイルに問題があるおそれがある場合、-XXnoJrDump オプションを使用してテキスト dump ファイルを無効にできます。
バイナリ クラッシュ ファイルを無効にするには、-XXdumpSize:none オプションを使用します。
JVM クラッシュは、jvm で適切に処理できなかった何かが発生したことを意味します。原因が JVM のプログラミング エラーである場合もありますが、クラッシュが Java コードまたは JVM セットアップの問題を示すこともあります。dump ファイルは、問題を特定するための、初期段階のトラブルシューティングの良い情報源です。
クラッシュが発生した原因が必ずしも dump ファイルに詳細に示されているわけではありませんが、JRockit JVM が実行されていた場所と、クラッシュが発生したときの JVM の状態は記録されています。これにより、調査を始める場所と、クラッシュのタイプについて推測できる可能性があります。ただし、dump ファイルには、次のようにして、簡単に特定できる兆候が示されています。
dump ファイルの StackOverFlow フィールドをチェックします。このフィールドが、スタック オーバーフロー エラーが発生していることを示している場合、クラッシュはスタック オーバーフローが原因である可能性があります。スタック オーバーフロー のクラッシュの処理方法については、「スタック オーバーフローのクラッシュ」を参照してください。Error message フィールドまたは dump ファイルの 末尾近くにあるスタック トレースの Stack Overflow のレポートをチェックします。これらが発生している場合も、スタック オーバーフローが原因であることを示している可能性があります。スタック オーバーフロー のクラッシュの処理方法については、「スタック オーバーフローのクラッシュ」を参照してください。dump ファイルの C Heap フィールドをチェックします。このフィールドが、メモリ割り当てエラーが発生していることを示している場合は、プロセスで仮想メモリが不足している可能性があります。仮想メモリ不足エラーの処理方法については、「仮想メモリ不足のクラッシュ」を参照してください。dump ファイルの LD_ASSUME_KERNEL フィールドをチェックします。この Linux 固有の環境変数を設定すると、サポートされないシステム ライブラリを JRockit JVM が使用することになるため、動作が不安定になります。サポートされない Linux コンフィグレーションの問題の処理方法については、「サポートされない Linux コンフィグレーションのクラッシュ」を参照してください。
dump ファイルに当てはまる兆候がない場合は、「JVM クラッシュ」の情報を使用してさらにトラブルシューティングを行うか、またはサポートに問い合わせることができます。サポートに問い合わせるには、Oracle とサービス契約を結んでいる必要があります。
この節では、テキスト dump ファイルの表示例を示し、dump ファイルの各部について説明します。ここでは、より多くのクラッシュのシナリオを紹介できるように、多数のテキスト dump ファイルを組み合わせた例を使用しました。
クラッシュの際に何が起きたのかが、テキスト クラッシュ ファイルにすべて記述されるわけではありません。また、JVM が作成するテキスト クラッシュ ファイルのレイアウトは、ここで例示するものと異なる場合があります。
コード リスト 31-1 は、dump ファイルの最初の部分の例を示しています。
コード リスト 31-1 には、テキスト dump ファイルの冒頭の部分が示されています。このセクションには、クラッシュが発生した時刻と、JVM がいつから実行されていたかが記録されます。その下には、キストとバイナリのクラッシュ ファイルの場所が示されています。
Oracle とサービス契約を結んでいる場合は、Oracle サービス プロバイダにサポートを依頼することができます。サービス契約を結んでいなくても、Oracle JRockit JDK 開発者フォーラムの jrockit.developer.interest.general で問題を投稿することができます。このフォーラムに問題を投稿しても、必ず解決するとは限りませんが、このフォーラムからは JRockit JVM の問題に関して有用な情報を得ることができます。
Error Message で始まるブロックには、クラッシュ時に OS が送出した実際のエラー メッセージが記述されます。オペレーティング システム ベンダによるユーザ情報をチェックして、エラーの詳細を調べてください。
Version 以降の記述を参照して、実行中の JRockit JVM のバージョンが最新かどうかを確認します。サポート対象のバージョンの一覧については、「Oracle JRockit でサポート対象のコンフィグレーション」を参照してください。
GC は Garbage Collector の略です。どのガベージ コレクタを使用していたかがここに記述されます。この例では、世代別コンカレント (gencon) ガベージ コレクタが使用されていました。世代別のガベージ コレクタが使用されているため、メモリのどこからナーサリが始まり、どこで終わっているかが記述されています。mmStartCompaction と mmEndCompaction の値にも、現在のまたは最新のガベージ コレクション時に、ヒープの圧縮がヒープのどこで行われたかが記述されています。
JRockit JVM でのメモリ管理の詳細については、「メモリ管理の概要」を参照してください。
CPU で始まるブロックには、使用されていた CPU の数と、java プロセス、アプリケーション、JRockit JVM によって消費されたメモリの量 (Tot Phys Mem) が記述されます。
OS version には、実行中のオペレーティング システムのバージョンが示されます。「Oracle JRockit JDK でサポート対象のコンフィグレーション」を参照して、サポート対象のオペレーティング システムのバージョンで実行していることを確認してください。
Thread フィールドには、クラッシュ時に JRockit JVM が使用していたスレッド システムが示されます。この例では、JVM は Native POSIX Thread Library (nptl) を使用していました。
クラッシュ時の JVM の state は running でした。この他に、starting up や shutting down が記述される場合があります。
コード リスト 31-2 に 2 番目の部分の例を示します。Command Line で始まる部分です。
Command Line には、起動時に JRockit JVM に送られたすべての起動オプションが記述されます。コード リスト 31-2 の例では、世代別コンカレント ガベージ コレクタ (-xgc:Gencon) を設定するためのコマンドライン オプションを使用し、Java ヒープの初期の最小値と最大値 (-Xms と -Xmx)、およびナーサリのサイズ (-Xns) が設定されています。
JAVA_HOME は java ホーム カタログ JVM がインストールされている場所) へのパスです。_JAVA_OPTIONS には、新しく起動するすべての JRockit JVMs に自動的に渡されるコマンドライン オプションが記述されます。
LD_LIBRARY_PATH は linux および solaris 固有の環境変数です。これは JVM がデフォルト システム ライブラリ以外のライブラリを検索するために使用されます。JNI コードを実行するために、この変数を設定することが必要になる場合があります。JVM がサポート対象でないライブラリを使用して、(そのライブラリ以外は) サポート対象のプラットフォームで起動するために、この変数を設定することができます。
LD_ASSUME_KERNEL で始まるブロックには、クラッシュの前に起きた可能性のある問題についての情報が記述されます。これらのフィールドで発見すべき点の詳細については、「発見すべき兆候」を参照してください。
コード リスト 31-3 に 3 番目の部分の例を示します。Registers で始まる部分です。
レジスタの節は Oracle のサポート担当者が問題を解決するときに使用します。レジスタの ESP がスタックの最初の数値と一致すれば (コード リスト 31-3 を参照)、テキスト クラッシュ ファイルが壊れていないことを確認できます。この 2 つの数値が一致しない場合、テキスト dump ファイルそのものが正しくない可能性があります。
このスタック情報に数値ではなく「unreadable」と表示されている場合、クラッシュの原因はおそらくスタック オーバーフローです。スタック情報のセクションは、通常はコード リスト 31-3 に示すものよりもはるかに長くなります。
Stack で始まるブロックをコード リスト 31-4 に示します。ここには、クラッシュ時に何が起きたのか、またそれがスレッド スタックのどこで発生したのかが記述されます。
Thread Stack Trace を見ると、JRockit JVM がクラッシュしたとき、クラッシュしているスレッドで何が実行されていたかがわかります。コード リスト 31-4 に、コードを生成している間にクラッシュが起きた場合の例を示します。
Stack 0: start=0x108c64000, end=0x108cc4000, guards=0x108cb0000 (ok), forbidden=0x108ca8000 Stack 1: start=0x108c44000, end=0x108c64000, guards=0x108c58000 (ok), forbidden=0x108c60000
Thread Stack Trace:
at get_constant_alen+576()@0x2000000000631110<!-- this is the crashing point
at get_constant_alen+256()@0x2000000000630fd0
at alength_opt+96()@0x2000000000631300
at optStrengthReduction+320()@0x2000000000631c80
at optmanOptimizeMIR+656()@0x20000000005efbf0
at generateMethodWithStage+256()@0x20000000004a2920
at cmgrGenerateMethodFromPhase+320()@0x20000000004a2a70
at cmgrGenerateNormalMethod+240()@0x20000000004a27b0
at cmgrGenerateCode+672()@0x20000000004a2310
at generate_code2+896()@0x2000000000702830
at codegenThread+1312()@0x20000000007031c0
at tsiCallStartFunction+48()@0x20000000007b3640
at tsiThreadStub+336()@0x20000000007b53d0
at ptiThreadStub+80()@0x20000000007995c0
at start_thread+352()@0x20000000001317f0
at __clone2+208()@0x20000000002fb9f0
-- Java stack --
Additional information is available in:
/usr/bea/user_projects/domains/jal/jrockit.17727.dump
/usr/bea/user_projects/domains/jal/core or core.17727
If you see this dump, please open a support case with Bea and supply as much information as you can on your system setup and the program you were running. You can also search for solutions to your problem at http://forums.bea.com in the forum jrockit.developer.interest.general.
Extended, platform specific info:
libc release: 2.3.4-stable
Elf headers:
libc ehdrs: EI: 7f454c46010101000000000000000000 ET: 3 EM: 3 V: 1 ENTRY: 004e8f20 PHOFF: 00000034 SHOFF: 001346c4 EF: 0x0 HS: 52 PS: 32 PHN; 10 SS: 40 SHN: 70 STIDX: 67
libpthread ehdrs: EI: 7f454c46010101000000000000000000 ET: 3 EM: 3 V: 1 ENTRY: 00704840 PHOFF: 00000034 SHOFF: 000107c4 EF: 0x0 HS: 52 PS: 32 PHN; 9 SS: 40 SHN: 39 STIDX: 36
libjvm ehdrs: EI: 7f454c46010101000000000000000000 ET: 3 EM: 3 V: 1 ENTRY: 0004ff30 PHOFF: 00000034 SHOFF: 0029d7c4 EF: 0x0 HS: 52 PS: 32 PHN; 3 SS: 40 SHN: 20 STIDX: 17
===== END DUMP =======================================================
|