| Oracle® JRockit診断およびトラブルシューティング・ガイド リリースR28 B61438-02 |
|
 前 |
 次 |
JRockit JVMがクラッシュすると、クラッシュ時のコンピュータの状態とJVMプロセスのスナップショットが作成されます。これらのスナップショットはテキスト・クラッシュ・ファイル(.dump)と、バイナリ・クラッシュ・ファイル(Windowsプラットフォームのミニダンプである.mdmp、またはLinuxおよびSolarisのプラットフォームのコア・ファイルである.core)という2つのクラッシュ・ファイル形式で表されます。クラッシュ・ファイルの名前はjrockit.pid.dumpとjrockit.pid.mdmp/coreで、pidはプロセスIDを表します(例: jrockit.72.dump)。
クラッシュ・ファイルの情報を使用して、JVMがクラッシュする原因となった問題を判断することができます。クラッシュ・ファイルの情報は、Oracleサポート担当者がJVMの問題解決を支援する場合にも不可欠です。
この章では、各クラッシュ・ファイルの違いと、それらを有効または無効にする方法について説明します。また、テキスト・クラッシュ・ファイルの例を示し、テキスト・クラッシュ・ファイルをトラブルシューティングに使用する方法を説明します。
この章の内容は以下のとおりです。
テキスト・クラッシュ・ファイル(.dump)はどのテキスト・エディタでも開くことができます。このファイルには、クラッシュの原因に関するヒントを示す情報が含まれます(8.6.2項「テキスト・ダンプ・ファイルの例」を参照)。
バイナリ・クラッシュ・ファイル(.coreまたは.mdmp)はデバッガで開くことができます。このクラッシュ・ファイルには、JRockit JVMの全プロセスに関する情報が含まれます。
クラッシュ・ファイルの作成はデフォルトで有効になっています。
LinuxおよびSolarisシステムでは、ulimit -cをゼロよりも大きな値に設定する必要があります(推奨設定: ulimit -c unlimited)。この値はブロック単位で測定され、各ブロックは1KBに相当します。値はコマンドラインでもシェル・スクリプトでも指定できます。
テキスト・クラッシュ・ファイルとバイナリ・クラッシュ・ファイルは現在の作業ディレクトリに保存されます。
別のディレクトリにクラッシュ・ファイルを保存する場合は、JROCKIT_DUMP_PATH環境変数を使用してディレクトリを指定します。
LinuxおよびSolarisの場合:
export JROCKIT_DUMP_PATH=path_to_directory
Windowsの場合:
set JROCKIT_DUMP_PATH=path_to_directory
指定するディレクトリは、既存の書込み可能なディレクトリにしてください。
テキスト・クラッシュ・ファイルは通常、100KB未満の小さなファイルですが、バイナリ・クラッシュ・ファイルは非常に大きい場合がほとんどです。これは、JRockit JVMではデフォルトで、全JVMプロセスがバイナリ・クラッシュ・ファイルに記録されるためです。したがって、ディスクに書き込まれるバイナリ・クラッシュ・ファイルに対して十分なディスク領域があることが必要です。
クラッシュ・ファイルのサイズを設定するには、-XXdumpSizeコマンドライン・オプションを使用します。デフォルト設定は-XXdumpSize:largeで、これによって、Javaヒープを含む全JVMプロセスの情報が含まれるバイナリ・クラッシュ・ファイルが生成されます。smallやnormalを設定することもできますが、これらの設定ではJavaヒープがクラッシュ・ファイルから除外されるため、いずれのサイズもJVMクラッシュのトラブルシューティングには不十分です。
クラッシュ・ファイルが書き込まれるディスク上に、バイナリ・クラッシュ・ファイルに対する十分な領域がない場合、ファイルは可能なかぎり、つまりディスクが一杯になるまで大きくなります。
図8-2はsmall、normal、largeのバイナリ・クラッシュ・ファイルの情報の違いを図示しています。
|
注意: Oracleサポートへのご連絡の際は、必ずlargeのバイナリ・クラッシュ・ファイルをご提供ください。 |
クラッシュの発生時にアプリケーションおよびJRockit JVMのプロセスに関してできるだけ多くの情報を得られるようにするため、クラッシュ・ファイルの作成はデフォルトで有効になっています。しかし、クラッシュ・ファイルの作成を無効にした方が都合がよい場合もあります(たとえば、ディスク領域が限られている場合)。
クラッシュ・ファイルの作成を無効にする前に、テキスト・クラッシュ・ファイルは小さいながらも、JVMの問題点の概要を把握するための有効な情報源となることに注意してください。バイナリ・クラッシュ・ファイルはOracleサポートへの連絡時に必ず必要です。
テキスト・クラッシュ・ファイルの作成を無効にするには、-XX:-DumpOnCrashコマンドライン・オプションを使用します。
バイナリ・クラッシュ・ファイルの作成を無効にするには、-XX:-CoreOnCrashコマンドライン・オプションを使用します。
JVMクラッシュは、JVMで適切に処理できなかった何かが発生したことを意味します。考えられる原因としては、JVMのプログラミング・エラー、Javaコードの問題、JVMセット・アップの問題、またはJVMプロセスでロードされたサードパーティ・ライブラリなどがあります。
テキスト・クラッシュ・ファイル(.dump)は、問題を診断するためのよい開始点となります。
テキスト・クラッシュ・ファイルには、クラッシュが発生した原因が必ずしも詳しく示されているわけではありませんが、JRockit JVMが実行されていた環境と、クラッシュが発生したときのJVMの状態は記録されています。
テキスト・クラッシュ・ファイルで調べることができる、簡単に特定可能な兆候を次にいくつか示します。
スタック・オーバーフロー・エラーが発生したことをStackOverFlowフィールドが示す場合、クラッシュはスタック・オーバーフローが原因である可能性があります。
Error messageフィールドまたはクラッシュ・ファイルの末尾近くにあるスタック・トレースの、Stack Overflowのレポートを調べます。これらが発生している場合も、スタック・オーバーフローを示している可能性があります。
スタック・オーバーフローが原因のクラッシュのトラブルシューティングについては、6.3項「スタック・オーバーフローのクラッシュ」を参照してください。
C Heapフィールドが、メモリー割当てが失敗したことを示している場合は、プロセスで仮想メモリーが不足している可能性があります。仮想メモリー・エラーが原因のクラッシュのトラブルシューティングについては、6.2項「仮想メモリー不足のクラッシュ」を参照してください。
この項で説明した兆候とは異なる兆候がテキスト・クラッシュ・ファイルに示されている場合は、6.5項「JVMクラッシュ」の情報を使用してトラブルシューティングを試行してください。
この項ではテキスト・クラッシュ・ファイル(.dump)の例を示し、各部分について説明します。
クラッシュの際に何が起きたのかが、テキスト・クラッシュ・ファイルにすべて記述されるわけではありません。JVMで生成されるファイルのレイアウトは、例示するレイアウトと異なる場合があります。
表8-1 テキスト・クラッシュ・ファイル(.dump)の例
| セクション | 内容 |
|---|---|
|
|
===== BEGIN DUMP ============================================================= JRockit dump produced after 0 days, 00:00:01 on Mon Dec 7 16:28:40 2009 Additional information is available in: /localhome/mycomp/gdbtest/jrockit.17470.dump /localhome/mycomp/gdbtest/core or core.17470 |
|
|
Error Message: Illegal memory access. [54] Signal info : si_signo=11, si_code=1 si_addr=0x7 |
|
|
Version : Oracle JRockit(R) R28.0.0-606-124955-1.6.0_17-20091130-2120-linux-ia32 |
|
|
CPU : Intel Pentium 4 (HT) SSE SSE2 NetBurst Number CPUs : 8 Tot Phys Mem : 8248045568 (7865 MB) |
|
|
OS version : Red Hat Enterprise Linux AS release 4 (Nahant Update 8) Linux version 2.6.9-89.0.0.0.1.ELsmp (mockbuild@ca-build10.us.oracle.com) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-11.0.1)) #1 SMP Tue May 19 04:23:49 EDT 2009 (i686) |
|
|
Thread System: Linux NPTL LibC release : 2.3.4-stable Java locking : Lazy unlocking enabled (class banning) (transfer banning) State : JVM is running |
|
|
Command Line : -Djava.library.path=. -Dsun.java.launcher=SUN_STANDARD Crash -static write |
|
|
java.home : /localhome/jrockits/R28.0.0_R28.0.0-606_1.6.0/jre j.class.path : . j.lib.path : . JAVA_HOME : /localhome/jrockits/R27.6.3_R27.6.3-40_1.6.0 LD_LIBRARY_PATH: /localhome/jrockits/R28.0.0_R28.0.0-606 _1.6.0/jre/lib/i386/jrockit:/localhome/jrockits/R28.0.0 _R28.0.0-606_1.6.0/jre/lib/i386:/localhome/jrockits/R28.0.0 _R28.0.0-606_1.6.0/jre/../lib/i386 |
|
|
GC Strategy : Mode: throughput, with strategy: genparpar (basic strategy: genparpar)
GC Status : OC is not running. Last finished OC was OC#0.
: YC is not running. Last finished YC was YC#0.
YC History : Ran 0 YCs since last OC.
Heap : 0x76eb7000 - 0x7aeb7000 (Size: 64 MB)
Compaction : (no compaction area)
NurseryList : 0x76eb7000 - 0x78eb7000
KeepArea : 0x786b6fe8 - 0x78eb7000
KA Markers : [ 0x77eb6ff0, 0x786b6fe8 , 0x78eb7000 ]
|
|
|
Registers (from ThreadContext: 0xb7ba4e60: eax = 00000007 ecx = b7ba519c edx = 00000000 ebx = b7ba6f70 esp = b7ba514c ebp = b7ba5150 esi = b7ba5178 edi = b7ba70f4 es = 0000007b cs = 00000073 ss = 0000007b ds = 0000007b fs = 00000000 gs = 00000033 eip = 74405765 eflags = 00000292 Stack:(* marks the word pointed to by the stack pointer) b7ba514c: 00000007* b7ba5170 7440584c 00000007 b7ba6f70 00000001 b7ba5164: 74bb4405 00000007 00000000 00000001 746a9f80 b7ba70f4 b7ba517c: b7ba519c 00000007 00000000 74bb4400 744842a0 746a9f7b b7ba5194: b7ba7228 b7ba5178 770643d0 b7ba6f70 00000001 770650d8 |
|
|
Thread:
"Main Thread" id=1 idx=0x4 tid=17471 lastJavaFrame=0xb7ba518c
Stack 0: start=0xb71a5000, end=0xb7ba6000, guards=0xb71aa000 (ok), forbidden=0xb71a8000
Thread Stack Trace:
at write+15()@0x74405765
at Java_Crash_staticWrite+28()@0x7440584c
-- Java stack --
at Crash.staticWrite(J)V(Native Method)[optimized]
at Crash.run(Crash.java:62)
at Crash.main(Crash.java:121)
at jrockit/vm/RNI.c2java(IIIII)V(Native
Method)[optimized]
-- end of trace
|
|
|
Memory usage report:
Total mapped 1133412KB (reserved=0KB)
- Java heap 1048576KB (reserved=983040KB)
- GC tables 35084KB
- Thread stacks 13332KB (#threads=18)
- Compiled code 384KB (used=256KB)
- Internal 520KB
- OS 7996KB
- Other 0KB
- JRockit malloc 24448KB (malloced=24397KB #290077)
Does not track allocation sites!
- Native memory tracking 1024KB (malloced=46KB #11)
Does not track allocation sites!
- Java class data 2048KB (malloced=1820KB #2455)
Does not track allocation sites!
Set the env variable TRACE_ALLOC_SITES=1 or use the
print_memusage switch trace_alloc_sites=1 to enable
alloc site tracing.
|
テキスト・クラッシュ・ファイルの冒頭
.dumpファイルのこの部分には、クラッシュが発生した時刻とJVMがいつから実行されていたかに関する情報が含まれます。
また、クラッシュのトラブルシューティングに役立つ情報へのリンクも示されます。
ファイルの場所は、テキスト・クラッシュ・ファイルとバイナリ・クラッシュ・ファイルの場所を指します。
オペレーティング・システムからのエラー・メッセージ
.dumpファイルのこの部分には、クラッシュ時にOSがスローしたエラー・メッセージが含まれます。エラーの詳細は、使用しているオペレーティング・システムのドキュメントを参照してください。
JRockit JVMのバージョン
.dumpファイルのこの部分には、JRockit JVMのリリース番号が示されます。
CPUおよびメモリー情報
.dumpファイルのこの部分には、システムのCPU、使用されたCPUの数や、Javaプロセス、アプリケーションまたはJRockit JVMで消費されたメモリーの量が示されます。
オペレーティング・システムのバージョン情報
.dumpファイルのこの部分には、JRockit JVMが実行されているオペレーティング・システムのバージョンが示されます。JRockit JVMがサポート対象のオペレーティング・システムで実行されているか確認してください。
詳細は、次の場所にある「Oracle JRockit JDK Supported Configurations」を参照してください。http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
スレッドと状態の情報
.dumpファイルのこの部分には、クラッシュ時にJRockit JVMが使用していたスレッド・システムと、JVMの状態が示されます。この例では、JVMはNative POSIX Thread Library (NPTL)を使用していました。
コマンドライン・オプションの情報
.dumpファイルのこの部分には、JVMの起動時に使用されたすべてのコマンドライン・オプションが表示されます。
環境情報
.dumpファイルのこの部分には、JVM環境に関する情報が示されます。
JAVA_HOMEは、Javaホーム・カタログへのパス、つまりJRockit JVMがインストールされているディレクトリです。
_JAVA_OPTIONSには、新しく起動するすべてのJRockit JVMに自動的に渡されるコマンドライン・オプションが表示されます。
LD_LIBRARY_PATHはLinuxおよびSolaris固有の環境変数です。これはJRockit JVMがデフォルト・システム・ライブラリ以外のライブラリを検索するために使用されます。この変数は、JNIコードの実行のために設定が必要になる場合もあります。
ガベージ・コレクション情報
.dumpファイルのこの部分には、ガベージ・コレクション・モードが示されます。
使用されたガベージ・コレクション・モードに応じて、.dumpファイルのこの部分には、ナーサリの場所やメモリー内の保持領域などの他の情報が表示される可能性があります。
レジスタおよびスタック情報
.dumpファイルのこの部分には次の情報が示されます。
Registersセクションは、Oracleサポート担当者によるトラブルシューティングに有効です。espレジスタの値がスタックの最初の数値と一致しない場合、テキスト・クラッシュ・ファイルが正しくない可能性があります。
Stackセクションにunreadableと表示されている場合、クラッシュの原因はおそらくスタック・オーバーフローです。スタック情報のセクションは通常、例に示すものよりもはるかに長くなります。
スレッドのスタック・トレース情報
.dumpファイルのこの部分には、JRockit JVMがクラッシュしたとき、クラッシュしたスレッドで何が行われていたかが示されます。
メモリー使用量の情報
.dumpファイルのこの部分には、(ネイティブ・メモリーを含む)メモリー使用量の詳細が表示されます。
HPROFは、ヒープ分析ツールが解析可能な特定の形式でヒープ・ダンプを生成する、ヒープ・プロファイリング・ツールです。
HPROFバイナリ形式でJavaヒープのダンプを生成するようにOracle JRockit JVMを設定するには、次のコマンドライン・オプションを使用します。
-XX:+HeapDumpOnOutOfMemoryError: メモリー不足エラーが発生したときに、Javaヒープ・ダンプの生成を有効にします。
-XX:+HeapDumpOnCtrlBreak: [Ctrl]+[Break]を押したときに、Javaヒープ・ダンプの生成を有効にします。
これらのコマンドライン・オプションやその他の関連オプションの詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
hprof診断コマンドを使用すると、JavaヒープのHPROF形式化されたダンプを生成することもできます。詳細は、Oracle JRockit JDKツールを参照してください。
HPROFツールの詳細は、http://java.sun.com/developer/technicalArticles/Programming/HPROF.htmlを参照してください。
