| Java Platform, Standard Editionトラブルシューティング・ガイド リリース9 E90916-02 |
|
 前 |
 次 |
致命的エラー・ログ、およびその場所と内容について説明します。
致命的エラー・ログは、致命的エラーの発生時に作成されます。それには、致命的エラーの発生時に取得された情報と状態が含まれています。
注意:
更新リリースではこのファイルの形式が若干変わる可能性があります。
この付録の内容は次のとおりです。
このログ・ファイルが作成される場所を指定するには、-XX:ErrorFile=fileという製品フラグ(fileはそのログ・ファイルの場所を表すフル・パス)を使用します。
file変数内の%%という部分文字列は%に変換され、%pという部分文字列はプロセスのPIDに変換されます。
次の例では、エラー・ログ・ファイルが/var/log/javaディレクトリに書き込まれ、java_errorpid.logという名前が付けられます。
java -XX:ErrorFile=/var/log/java/java_error%p.log
-XX:ErrorFile=fileフラグを指定しない場合、デフォルトのログ・ファイル名はhs_err_pid.log ( pidはプロセスのPID)になります。
また、-XX:ErrorFile=fileフラグを指定しない場合、システムはそのファイルをプロセスの作業ディレクトリに作成しようとします。作業ディレクトリにファイルを作成できない場合(領域不足、アクセス権の問題、またはその他の問題がある場合)は、オペレーティング・システムの一時ディレクトリにファイルが作成されます。Oracle SolarisおよびLinuxオペレーティング・システムの一時ディレクトリは/tmpです。Windowsでは、一時ディレクトリは環境変数TMPの値で指定されます。この環境変数が指定されていないと、TEMP環境変数の値が使用されます。
致命的エラー・ログの説明および致命的エラーの発生時に取得された情報について説明する項。
エラー・ログには、可能であれば次の情報を含む、致命的エラーの発生時に取得された情報が含まれています。
致命的エラーを引き起こした操作例外またはシグナル
バージョンおよび構成情報
致命的エラーを引き起こしたスレッドの詳細およびスレッドのスタック・トレース
実行中のスレッドとその状態のリスト
ヒープに関するサマリー情報
ロードされているネイティブ・ライブラリのリスト
コマンド行引数
環境変数
オペレーティング・システムおよびCPUの詳細
注意:
この情報の一部しかエラー・ログに出力されない場合もあります。これが起こる可能性があるのは、致命的エラーの深刻度が高いため、エラー・ハンドラが一部の詳細情報しか復元および報告できない場合です。
エラー・ログは、次のセクションで構成されるテキスト・ファイルです。
クラッシュについて簡単に説明するヘッダー。「ヘッダー形式」を参照してください。
スレッド情報を含むセクション。「スレッド・セクションの形式」を参照してください。
プロセス情報を含むセクション。「プロセス・セクションの形式」を参照してください。
システム情報を含むセクション。「システム・セクションの形式」を参照してください。
注意:
ここで説明している致命的エラー・ログの形式はJava SE 6に基づいています。その他のリリースでは形式が異なる場合があります。
すべての致命的エラー・ログ・ファイルの先頭にあるヘッダー・セクションには、問題の簡易説明が含まれます。
このヘッダーは、標準出力にも出力されるほか、アプリケーションの出力ログに現れる可能性もあります。
ヘッダーにはHotSpot仮想マシン・エラー報告ページへのリンクが含まれていますが、そのページではユーザーがバグ・レポートを提出できます。
# # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f0f159f857d, pid=18240, tid=18245 # # JRE version: Java(TM) SE Runtime Environment (9.0+167) (build 9-ea+167) # Java VM: Java HotSpot(TM) 64-Bit Server VM (9-ea+167, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # C [libMyApp.so+0x57d] Java_MyApp_readData+0x11 # # Core dump will be written. Default location: /cores/core.18240) # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. #
この例は、予期しないシグナルによってVMがクラッシュしたことを示しています。
次の例に示すように、次の行には、シグナルのタイプ、シグナルの原因となったプログラム・カウンタ(pc)、プロセスID、およびスレッドIDが記述されています。
# SIGSEGV (0xb) at pc=0x00007f0f159f857d, pid=18240, tid=18245
| | | | +--- thread id
| | | +------------- process id
| | +--------------------------- program counter
| | (instruction pointer)
| +--------------------------------------- signal number
+---------------------------------------------- signal name
次の例に示すように、次の行には、VMのバージョン(Client VMまたはServer VM)、アプリケーションが混合モード、インタプリタ・モードのどちらで実行されたかを示す情報、およびクラス・ファイル共有が有効かどうかを示す情報が含まれます。
# Java VM: Java HotSpot(TM) 64-Bit Server VM (9-ea+167, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
次の例に示すように、その次の情報は、クラッシュの原因となった関数フレームです。
# Problematic frame: # C [libMyApp.so+0x57d] Java_MyApp_readData+0x11 | +-- Same as pc, but represented as library name and offset. | For position-independent libraries (JVM and most shared | libraries), it is possible to inspect the instructions | that caused the crash without a debugger or core file | by using a disassembler to dump instructions near the | offset. +----------------- Frame type
この例のフレーム・タイプ「C」は、ネイティブCフレームを示しています。表A-1は、可能なフレーム・タイプを示しています。
表A-1 フレーム・タイプ
| フレーム・タイプ | 説明 |
|---|---|
C |
ネイティブCフレーム |
j |
解釈済Javaフレーム |
V |
VMフレーム |
v |
VM生成のスタブ・フレーム |
J |
その他のフレーム・タイプ(コンパイル済みJavaフレームなど) |
内部エラーが発生した場合も、VMエラー・ハンドラによって似たようなエラー・ダンプが生成されます。ただし、ヘッダー形式が異なります。内部エラーの例としては、guarantee()の失敗、アサーションの失敗、ShouldNotReachHere()などが挙げられます。次の例は、内部エラーのヘッダー形式を示しています。
# # An unexpected error has been detected by HotSpot Virtual Machine: # # Internal Error (4F533F4C494E55583F491418160E43505000F5), pid=10226, tid=16384 # # Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b63 mixed mode)
上のヘッダーにはシグナル名やシグナル番号がありません。2行目にはかわりに、Internal Errorと長い16進文字列が含まれるようになっています。この16進文字列は、エラーが検出されたソース・モジュールと行番号をエンコードしたものです。この「エラー文字列」は一般に、HotSpot仮想マシンを操作するエンジニアにしか役に立ちません。
エラー文字列は行番号をエンコードしているため、コード変更やリリースのたびに変わります。あるリリース(1.6.0など)の特定のエラー文字列を含むクラッシュは、(文字列が一致する場合でも)更新リリース(1.6.0_01など)の同じクラッシュに対応しない可能性があります。
注意:
特定のエラー文字列に関連する1つの状況で機能した回避方法や解決方法は、その同じエラー文字列に関連する別の状況でも機能すると考えないでください。次の事実に注意してください。
エラーの根本的原因が同じでも、エラー文字列は異なることがあります。
エラーのエラー文字列が同じでも、根本的原因は完全に異なることがあります。
したがって、バグのトラブルシューティングを行う際に、エラー文字列を唯一の基準として使用すべきではありません。
クラッシュしたスレッドに関する情報。
複数のスレッドが同時にクラッシュした場合、1つのスレッドのみが出力されます。
スレッド情報
スレッド・セクションの最初の部分は、次の例に示すように、致命的エラーを起こしたスレッドを示しています。
Current thread (0x00007f102c013000): JavaThread "main" [_thread_in_native, id=18245, stack(0x00007f10345c0000,0x00007f10346c0000)]
| | | | | + stack
| | | | +------------------ ID
| | | +------------------------------- state
| | +-------------------------------------------- name
| +------------------------------------------------------ type
+----------------------------------------------------------------------------- pointer
スレッド・ポインタは、Java VM内部のスレッド構造体へのポインタです。ライブJava VMやコア・ファイルのデバッグを行なっているのでないかぎり、これは一般に役に立ちません。
次の一覧は、可能性のあるスレッド・タイプを示したものです。
JavaThread
VMThread
CompilerThread
GCTaskThread
WatcherThread
ConcurrentMarkSweepThread
表A-2は、重要なスレッド状態を示しています。
表A-2 スレッドの状態
| スレッド状態 | 説明 |
|---|---|
|
スレッドが作成されていません。これが発生するのは、メモリーが破損した場合だけです。 |
|
スレッドは作成済ですがまだ開始されていません。 |
|
スレッドはネイティブ・コードを実行しています。エラーはおそらくネイティブ・コードのバグです。 |
|
スレッドはVMコードを実行しています。 |
|
スレッドは、解釈済みまたはコンパイル済みのJavaコードを実行しています。 |
|
スレッドがブロックされています。 |
|
前のいずれかの状態の後に |
出力に含まれるスレッドIDは、ネイティブ・スレッド識別子です。
Javaスレッドがデーモン・スレッドの場合、スレッドの状態の前にdaemonという文字列が出力されます。
シグナル情報
エラー・ログ内のその次の情報は、VMが終了する原因となった予期しないシグナルの説明です。Windowsシステムでは、出力は次の例のように表示されます。
siginfo: ExceptionCode=0xc0000005, reading address 0xd8ffecf1
前述の例では、例外コードは0xc0000005 (ACCESS_VIOLATION)であり、スレッドがアドレス0xd8ffecf1を読み取ろうとしたときに例外が発生しました。
Oracle SolarisおよびLinuxオペレーティング・システムでは次のように、例外を識別するためにシグナル番号(si_signo)とシグナル・コード(si_code)が使用されます。
siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000000
レジスタ・コンテキスト
エラー・ログ内のその次の情報は、致命的エラー発生時のレジスタ・コンテキストを示します。この出力の実際の形式はプロセッサに依存します。次の例は、Intel(R) Xeon(R)プロセッサの出力を示したものです。
Registers: RAX=0x0000000000000000, RBX=0x00007f0f17aff3b0, RCX=0x0000000000000001, RDX=0x00007f1033880358 RSP=0x00007f10346be930, RBP=0x00007f10346be930, RSI=0x00007f10346be9a0, RDI=0x00007f102c013218 R8 =0x00007f0f17aff3b0, R9 =0x0000000000000008, R10=0x00007f1011bb1de9, R11=0x0000000101cfc5e0 R12=0x0000000000000000, R13=0x00007f0f17aff3b0, R14=0x00007f10346be9a8, R15=0x00007f102c013000 RIP=0x00007f0f159f857d, EFLAGS=0x0000000000010283, CSGSFS=0x0000000000000033, ERR=0x0000000000000004
レジスタの値は、次に説明する命令と組み合わせると、役立つ可能性があります。
機械命令
レジスタ値の後、次の例に示すように、エラー・ログには、システムがクラッシュしたときのスタックの最上段と、プログラム・カウンタ(PC)付近の32バイトの命令(操作コード)が含まれています。これらの操作コードを逆アセンブラでデコードすれば、クラッシュの場所の近くにあった命令を生成できます。注意: IA32およびAMD64命令は可変長であるため、常にクラッシュPCの前の命令を間違いなくデコードできるとはかぎりません。
Top of Stack: (sp=0x00007f10346be930) 0x00007f10346be930: 00007f10346be990 00007f1011bb1e15 0x00007f10346be940: 00007f1011bb1b33 00007f10346be948 0x00007f10346be950: 00007f0f17aff3b0 00007f10346be9a8 0x00007f10346be960: 00007f0f17aff5a0 0000000000000000 Instructions: (pc=0x00007f0f159f857d) 0x00007f0f159f855d: 3d e6 08 20 00 ff e0 0f 1f 40 00 5d c3 90 90 55 0x00007f0f159f856d: 48 89 e5 48 89 7d f8 48 89 75 f0 b8 00 00 00 00 0x00007f0f159f857d: 8b 00 5d c3 90 90 90 90 90 90 90 90 90 90 90 90 0x00007f0f159f858d: 90 90 90 55 48 89 e5 53 48 83 ec 08 48 8b 05 88
スレッド・スタック
次の例に示すように、可能な場合、エラー・ログ内のその次の出力はスレッド・スタックです。これには、スタックのベースと先頭のアドレス、現在のスタック・ポインタ、およびスレッドで使用可能な未使用スタックの量が含まれます。このあとに可能であればスタック・フレームが続き、最大100件のフレームが出力されます。C/C++フレームの場合、ライブラリ名も出力される可能性があります。注意: 致命的エラーの状態によっては、スタックが破損している可能性があり、この詳細が利用できない場合があります。
Stack: [0x00007f10345c0000,0x00007f10346c0000], sp=0x00007f10346be930, free space=1018k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libMyApp.so+0x57d] Java_MyApp_readData+0x11 j MyApp.readData()I+0 j MyApp.main([Ljava/lang/String;)V+15 v ~StubRoutines::call_stub V [libjvm.so+0x839eea] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x47a V [libjvm.so+0x896fcf] jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) [clone .isra.90]+0x21f V [libjvm.so+0x8a7f1e] jni_CallStaticVoidMethod+0x14e C [libjli.so+0x4142] JavaMain+0x812 C [libpthread.so.0+0x7e9a] start_thread+0xda Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j MyApp.readData()I+0 j MyApp.main([Ljava/lang/String;)V+15 v ~StubRoutines::call_stub
ログには2つのスレッド・スタックが含まれます。
1つ目のスレッド・スタックはNative framesであり、すべての関数呼出しを示すネイティブ・スレッドを出力します。ただし、このスレッド・スタックはランタイム・コンパイラでインライン化されるJavaメソッドを考慮に入れません。そのため、インライン化されたメソッドは、親のスタック・フレームの一部として表示されます。
ネイティブ・フレームのスレッド・スタックの情報は、クラッシュの原因に関する重要な情報を提供します。リスト内のライブラリを上から順に分析すれば、通常は、問題の原因となったライブラリを特定し、そのライブラリを担当する適切な組織に問題を報告することができます。
2番目のスレッド・スタックであるJavaフレームでは、Javaフレーム(インライン化されたメソッドを含む)が出力され、ネイティブ・フレームはスキップされます。クラッシュによっては、ネイティブ・スレッド・スタックを出力できなくても、Javaフレームを出力できる可能性があります。
追加詳細
エラーがVMスレッドまたはコンパイラ・スレッドで発生した場合は、次の例の追加の詳細が表示されることがあります。たとえばVMスレッドの場合、致命的エラーの発生時にVMスレッドがVM操作を実行していた場合、そのVM操作が出力されます。次の出力例の場合、致命的エラーを起こしたのはコンパイラ・スレッドです。タスクはコンパイラ・タスクであり、HotSpot Client VMがメソッドhs101t004Thread.ackermannをコンパイルしています。
Current CompileTask: HotSpot Client Compiler:754 b nsk.jvmti.scenarios.hotswap.HS101.hs101t004Thread.ackermann(IJ)J (42 bytes)
HotSpot Server VMの場合はコンパイラ・タスクの出力が若干異なりますが、やはり完全なクラス名とメソッドを含んでいます。
プロセス・セクションはスレッド・セクションのあとに出力されます。
ここには、プロセスのスレッド・リストやメモリー使用状況など、プロセス全体に関する情報が含まれます。
スレッド・リスト
スレッド・リストには、次の例に示すように、VMが認識しているスレッドが含まれます。
=>0x0805ac88 JavaThread "main" [_thread_in_native, id=21139, stack(0x00007f10345c0000,0x00007f10346c0000)] | | | | | | + stack | | | | | +---------------------------------------- ID | | | | +------------------------------------------------------ state | | | | (JavaThread only) | | | +-------------------------------------------------------------------- name | | +----------------------------------------------------------------------------- type | +--------------------------------------------------------------------------------------- pointer +---------------------------------------------------------------------------------------------- "=>" current thread
これには、すべてのJavaスレッドおよび一部のVM内部スレッドが含まれますが、次の例に示すように、VMに接続していないユーザー・アプリケーションによって作成されたネイティブ・スレッドは含まれていません。
Java Threads: ( => current thread ) 0x00007f102c469800 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=18302, stack(0x00007f0f16f31000,0x00007f0f17032000)] 0x00007f102c468000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=18301, stack(0x00007f0f17032000,0x00007f0f17133000)] 0x00007f102c450800 JavaThread "Finalizer" daemon [_thread_blocked, id=18298, stack(0x00007f0f173fc000,0x00007f0f174fd000)] 0x00007f102c448800 JavaThread "Reference Handler" daemon [_thread_blocked, id=18297, stack(0x00007f0f174fd000,0x00007f0f175fe000)] =>0x00007f102c013000 JavaThread "main" [_thread_in_native, id=18245, stack(0x00007f10345c0000,0x00007f10346c0000)] Other Threads: 0x00007f102c43f000 VMThread "VM Thread" [stack: 0x00007f0f175ff000,0x00007f0f176ff000] [id=18296] 0x00007f102c54b000 WatcherThread [stack: 0x00007f0f15bfb000,0x00007f0f15cfb000] [id=18338]
スレッド・タイプやスレッド状態については、「スレッド・セクションの形式」で説明されています。
VMの状態
その次の情報はVMの状態で、これは仮想マシン全体の状態を示します。表A-3は、一般的な状態を説明しています。
表A-3 VMの状態
| 一般的なVMの状態 | 説明 |
|---|---|
|
正常実行。 |
|
特殊なVM操作が完了するまで、VM内のすべてのスレッドがブロックされています。 |
|
特殊なVM操作が必要となったため、VM内のすべてのスレッドがブロックされるまでVMが待機しています。 |
VM状態の出力は次のように、エラー・ログ内で1行になります。
VM state:not at safepoint (normal execution)
相互排他ロックとモニター
エラー・ログ内のその次の情報は、次の例に示すように、現在スレッドによって所有されている相互排他ロックとモニターのリストです。これらの相互排他ロックは、Javaオブジェクトに関連付けられたモニターではなく、VM内部のロックです。VMロックが保持された状態でクラッシュが発生した場合の出力を示す例を次に示します。ログにはロックごとに、ロックの名前、所有者、VM内部の相互排他ロック構造体のアドレス、およびそのOSロックのアドレスが含まれます。この情報は一般に、HotSpot VMにきわめて習熟したユーザーにしか役に立ちません。所有者スレッドはスレッド・リストと相互参照できます。
VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])[0x007357b0/0x0000031c] Threads_lock - owner thread: 0x00996318 [0x00735978/0x000002e0] Heap_lock - owner thread: 0x00736218
ヒープ・サマリー
次の例に示すように、その次の情報は、ヒープ・サマリーです。出力はガベージ・コレクション(GC)の構成に依存します。この例ではシリアル・コレクタが使用され、クラス・データ共有が無効にされ、Tenured世代が空になっています。これはおそらく、初期段階や起動中に致命的なエラーが発生し、GCがまだどのオブジェクトもTenured世代に昇格させていなかったことを示しています。
Heap def new generation total 576K, used 161K [0x46570000, 0x46610000, 0x46a50000) eden space 512K, 31% used [0x46570000, 0x46598768, 0x465f0000) from space 64K, 0% used [0x465f0000, 0x465f0000, 0x46600000) to space 64K, 0% used [0x46600000, 0x46600000, 0x46610000) tenured generation total 1408K, used 0K [0x46a50000, 0x46bb0000, 0x4a570000) the space 1408K, 0% used [0x46a50000, 0x46a50000, 0x46a50200, 0x46bb0000) compacting perm gen total 8192K, used 1319K [0x4a570000, 0x4ad70000, 0x4e570000) the space 8192K, 16% used [0x4a570000, 0x4a6b9d48, 0x4a6b9e00, 0x4ad70000) No shared spaces configured.
メモリー・マップ
ログ内のその次の情報は、クラッシュ時の仮想メモリー領域のリストです。アプリケーションが大きいと、このリストが長くなる可能性があります。メモリー・マップは一部のクラッシュをデバッグする際に非常に役立つ可能性がありますが、それは、実際に使用されていたライブラリやそのメモリー内での場所はもちろん、ヒープ、スタック、およびガード・ページの場所もわかるからです。
/proc/pid/maps)が出力されます。Windowsシステムでは各ライブラリのベース・アドレスと終了アドレスが出力されます。次の例は、Linux/x86で生成された出力を示しています。 注意:
この例では簡潔にするために、ほとんどの行を省略しました。Dynamic libraries: 00400000-00401000 r-xp 00000000 00:47 1374716350 /export/java_re/jdk/9/ea/167/binaries/linux-x64/bin/java 00601000-00602000 rw-p 00001000 00:47 1374716350 /export/java_re/jdk/9/ea/167/binaries/linux-x64/bin/java 016c6000-016e7000 rw-p 00000000 00:00 0 [heap] 82000000-102000000 rw-p 00000000 00:00 0 102000000-800000000 ---p 00000000 00:00 0 40014000-40015000 r--p 00000000 00:00 0 Lines omitted. 7f0f159f8000-7f0f159f9000 r-xp 00000000 08:11 116808980 /export/users/dh198349/tests/hs-err/libMyApp.so 7f0f159f9000-7f0f15bf8000 ---p 00001000 08:11 116808980 /export/users/dh198349/tests/hs-err/libMyApp.so 7f0f15bf8000-7f0f15bf9000 r--p 00000000 08:11 116808980 /export/users/dh198349/tests/hs-err/libMyApp.so 7f0f15bf9000-7f0f15bfa000 rw-p 00001000 08:11 116808980 /export/users/dh198349/tests/hs-err/libMyApp.so Lines omitted. 7f0f15dfc000-7f0f15e00000 ---p 00000000 00:00 0 7f0f15e00000-7f0f15efd000 rw-p 00000000 00:00 0 7f0f15efd000-7f0f15f13000 r-xp 00000000 00:47 1374714565 /export/java_re/jdk/9/ea/167/binaries/linux-x64/lib/libnet.so 7f0f15f13000-7f0f16113000 ---p 00016000 00:47 1374714565 /export/java_re/jdk/9/ea/167/binaries/linux-x64/lib/libnet.so 7f0f16113000-7f0f16114000 rw-p 00016000 00:47 1374714565 /export/java_re/jdk/9/ea/167/binaries/linux-x64/lib/libnet.so 7f0f16114000-7f0f16124000 r-xp 00000000 00:47 1374714619 /export/java_re/jdk/9/ea/167/binaries/linux-x64/lib/libnio.so Lines omitted. 7f0f17032000-7f0f17036000 ---p 00000000 00:00 0 7f0f17036000-7f0f17133000 rw-p 00000000 00:00 0 7f0f17133000-7f0f173fc000 r--p 00000000 08:02 2102853 /usr/lib/locale/locale-archive 7f0f173fc000-7f0f17400000 ---p 00000000 00:00 0 Lines omtted.
次に、エラー・ログ内のメモリー・マップの形式を示します。
40049000-4035c000 r-xp 00000000 03:05 824473 /jdk1.5/jre/lib/i386/client/libjvm.so
|<------------->| ^ ^ ^ ^ |<--------------------------------->|
Memory region | | | | |
| | | | |
Permission --- + | | | |
r: read | | | |
w: write | | | |
x: execute | | | |
p: private | | | |
s: share | | | |
| | | |
File offset ----------+ | | |
| | |
Major ID and minor ID of -------+ | |
the device where the file | |
is located (i.e. /dev/hda5) | |
| |
inode number ------------------------+ |
|
File name --------------------------------------------------+
この例に示されたメモリー・マップの出力では、各ライブラリに2つの仮想メモリー領域(コード用とデータ用に1つずつ)があります。コード・セグメントのアクセス権はr-xp (読取り可能、実行可能、非公開)でマークされ、データ・セグメントのアクセス権はrw-p (読取り可能、書込み可能、非公開)になります。
Javaヒープはすでに出力の前のほうのヒープ・サマリーに含まれていますが、ヒープ用に予約された実際のメモリー領域がヒープ・サマリーの値と一致することや、属性がrwxpに設定されていることを確認することは、有用である可能性があります。
スレッド・スタックは通常、メモリー・マップ内で連続する2つの領域、具体的にはアクセス権が---pの領域(ガード・ページ)とアクセス権がrwxpの領域(実際のスタック領域)として表示されます。さらに、ガード・ページ・サイズやスタック・サイズを知ることは有用です。たとえばこのメモリー・マップでは、スタックの場所は4127b000から412fb000です。
Windowsシステムでは次の例のように、メモリー・マップの出力は、ロードされた各モジュールのロード・アドレスと終了アドレスになります。
Dynamic libraries: 0x00400000 - 0x0040c000 c:\jdk6\bin\java.exe 0x77f50000 - 0x77ff7000 C:\WINDOWS\System32\ntdll.dll 0x77e60000 - 0x77f46000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e5d000 C:\WINDOWS\system32\ADVAPI32.dll 0x78000000 - 0x78087000 C:\WINDOWS\system32\RPCRT4.dll 0x77c10000 - 0x77c63000 C:\WINDOWS\system32\MSVCRT.dll 0x08000000 - 0x08183000 c:\jdk6\jre\bin\client\jvm.dll 0x77d40000 - 0x77dcc000 C:\WINDOWS\system32\USER32.dll 0x7e090000 - 0x7e0d1000 C:\WINDOWS\system32\GDI32.dll 0x76b40000 - 0x76b6c000 C:\WINDOWS\System32\WINMM.dll 0x6d2f0000 - 0x6d2f8000 c:\jdk6\jre\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\System32\PSAPI.DLL 0x6d680000 - 0x6d68c000 c:\jdk6\jre\bin\verify.dll 0x6d370000 - 0x6d38d000 c:\jdk6\jre\bin\java.dll 0x6d6a0000 - 0x6d6af000 c:\jdk6\jre\bin\zip.dll 0x10000000 - 0x10032000 C:\bugs\crash2\App.dll
VM引数と環境変数
エラー・ログ内のその次の情報は、次の例に示すように、VM引数のリストと、それに続く環境変数のリストです。
VM Arguments: jvm_args: java_command: MyApp java_class_path (initial): . Launcher Type: SUN_STANDARD Logging: Log output configuration: #0: stdout all=warning uptime,level,tags #1: stderr all=off uptime,level,tags Environment Variables: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin SHELL=/bin/bash DISPLAY=localhost:10.0 ARCH=i386
注意:
この環境変数のリストは、Java VMに適用可能な環境変数の完全なリストではなく、その一部です。
シグナル・ハンドラ
Oracle SolarisおよびLinuxオペレーティング・システムでは、次の例に示すように、エラー・ログ内のその次の情報はシグナル・ハンドラのリストです。
Signal Handlers: SIGSEGV: [libjvm.so+0xd48840], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGBUS: [libjvm.so+0xd48840], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGFPE: [libjvm.so+0xd48840], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGPIPE: [libjvm.so+0xb60080], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGXFSZ: [libjvm.so+0xb60080], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGILL: [libjvm.so+0xd48840], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGUSR2: [libjvm.so+0xb5ff40], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO SIGHUP: [libjvm.so+0xb60150], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGINT: [libjvm.so+0xb60150], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGTERM: [libjvm.so+0xb60150], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGQUIT: [libjvm.so+0xb60150], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
エラー・ログの最後のセクションは、システム情報です。その出力はオペレーティング・システムに固有ですが、一般にオペレーティング・システムのバージョン、CPU情報、およびメモリー構成に関するサマリー情報を含みます。
次の例では、Linuxオペレーティング・システムでの出力を示します。
--------------- S Y S T E M --------------- OS:DISTRIB_ID=Ubuntu DISTRIB_RELEASE=12.04 DISTRIB_CODENAME=precise DISTRIB_DESCRIPTION="Ubuntu 12.04 LTS" uname:Linux 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 libc:glibc 2.15 NPTL 2.15 rlimit: STACK 8192k, CORE infinity, NPROC 1160369, NOFILE 4096, AS infinity load average:0.46 0.33 0.27 /proc/meminfo: MemTotal: 148545440 kB MemFree: 1020964 kB Buffers: 29600728 kB Cached: 86607768 kB SwapCached: 16112 kB Active: 52272944 kB Inactive: 64862992 kB Active(anon): 314080 kB Inactive(anon): 616296 kB Active(file): 51958864 kB Inactive(file): 64246696 kB Unevictable: 16 kB Mlocked: 16 kB SwapTotal: 1051644 kB SwapFree: 976092 kB Dirty: 40 kB Writeback: 0 kB AnonPages: 912404 kB Mapped: 95804 kB Shmem: 2936 kB Slab: 28625980 kB SReclaimable: 28337400 kB SUnreclaim: 288580 kB KernelStack: 6040 kB PageTables: 42524 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 75324364 kB Committed_AS: 6172612 kB VmallocTotal: 34359738367 kB VmallocUsed: 681668 kB VmallocChunk: 34282379392 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 171520 kB DirectMap2M: 8208384 kB DirectMap1G: 142606336 kB CPU:total 24 (initial active 24) (6 cores per cpu, 2 threads per core) family 6 model 44 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, aes, clmul, ht, tsc, tscinvbit, tscinv CPU Model and flags from /proc/cpuinfo: model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm ida arat epb dts tpr_shadow vnmi flexpriority ept vpid Memory: 4k page, physical 148545440k(1020964k free), swap 1051644k(976092k free) vm_info: Java HotSpot(TM) 64-Bit Server VM (9-ea+167) for linux-amd64 JRE (9-ea+167), built on Apr 27 2017 00:28:45 by "javare" with gcc 4.9.2
Oracle SolarisおよびLinuxの場合、オペレーティング・システム情報はファイル/etc/*releaseにあります。このファイルは、アプリケーションが実行されているシステムの種類について説明し、場合によっては情報文字列にパッチ・レベルが含まれることもあります。/etc/*releaseファイルには一部のシステム・アップグレードが反映されません。ユーザーがシステムの任意の部分を構築し直せるLinuxシステムの場合は、特にそうなります。
Oracle Solarisオペレーティング・システムでは、unameシステム・コールを使用してカーネルの名前を取得します。スレッド・ライブラリ(T1またはT2)も出力されます。
Linuxシステムの場合もunameシステム・コールを使用してカーネル名が取得されます。次の例に示すように、libcのバージョンとスレッド・ライブラリのタイプも出力されます。
uname:Linux 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64
libc:glibc 2.15 NPTL 2.15
|<- glibc version ->|<-- pthread type -->|
Linuxの場合、可能なスレッド・タイプは3つあります(具体的にはlinuxthreads (fixed stack)、linuxthreads (floating stack)、およびNPTL)。これらは通常、/lib、/lib/i686、および/lib/tlsにインストールされます。
スレッド・タイプを知ることは有用です。たとえば、クラッシュがpthreadに関係しているように見える場合、別のpthreadライブラリを選択すれば問題を回避できる可能性があります。別のpthreadライブラリ(およびlibc)を選択するには、LD_LIBRARY_PATHまたはLD_ASSUME_KERNELを設定します。
glibcのバージョンには通常、パッチ・レベルは含まれません。コマンドrpm -q glibcを実行すると、より詳しいバージョン情報が得られる可能性があります。
rlimit情報です。 注意:
次の例に示すように、VMのデフォルトのスタック・サイズは通常、システムの制限より小さくなっています。rlimit: STACK 8192k, CORE infinity, NPROC 1160369, NOFILE 4096, AS infinity
| | | | virtual memory (-v)
| | | +--- max open files (ulimit -n)
| | +----------- max user processes (ulimit -u)
| +------------------------------ core dump size (ulimit -c)
+----------------------------------------- stack size (ulimit -s)
load average:0.04 0.05 0.02
rlimit: STACK 8192k, CORE 0k, NPROC 4092, NOFILE 1024, AS infinity
| | | | virtual memory (-v)
| | | +--- max open files (ulimit -n)
| | +----------- max user processes (ulimit -u)
| +------------------------- core dump size (ulimit -c)
+---------------------------------------- stack size (ulimit -s)
load average:0.04 0.05 0.02
その次の情報は、次の例に示すように、起動時にVMによって識別されたCPUのアーキテクチャと機能を指定します。
CPU:total 24 (initial active 24) (6 cores per cpu, 2 threads per core) family 6 model 44 stepping 2, cmov, cx8, fxsr, mmx
| | | |<----- CPU features ---->|
| |
| +--- processor family (IA32 only):
| 3 - i386
| 4 - i486
| 5 - Pentium
| 6 - PentiumPro, PII, PIII
| 15 - Pentium 4
+------------ Total number of CPUs
表A-4は、SPARCシステムで可能なCPU機能を示しています。
表A-4 SPARCの機能
| SPARCの機能 | 説明 |
|---|---|
|
v8命令をサポートします。 |
|
v9命令をサポートします。 |
|
視覚化命令をサポートします。 |
|
視覚化命令をサポートします。 |
|
UltraSparc III。 |
|
ハードウェア整数乗除なし。 |
|
Multiply-AddおよびMultiply-Subtract命令なし。 |
表A-5は、Intel/IA32システムで可能なCPU機能を示しています。
表A-5 Intel/IA32の機能
| Intel/IA32の機能 | 説明 |
|---|---|
|
cmov命令をサポートします。 |
|
cmpxchg8b命令をサポートします。 |
|
fxsaveとfxrstorをサポートします。 |
|
MMXをサポートします。 |
|
SSE拡張をサポートします。 |
|
SSE2拡張をサポートします。 |
|
ハイパースレッディング・テクノロジをサポートします。 |
表A-6は、AMD64/EM64Tシステムで可能なCPU機能を示しています。
表A-6 AMD64/EM64Tの機能
| AMD64/EM64Tの機能 | 説明 |
|---|---|
|
AMD Opteron、Athlon64など。 |
|
Intel EM64Tプロセッサ。 |
|
3DNow拡張をサポートします。 |
|
ハイパースレッディング・テクノロジをサポートします。 |
エラー・ログ内のその次の情報は、次の例に示すように、メモリー情報です。
unused swap space
total amount of swap space |
unused physical memory | |
total amount of physical memory | | |
page size | | | |
v v v v v
Memory: 4k page, physical 513604k(11228k free), swap 530104k(497504k free)
一部のシステムではスワップ空間が実際の物理メモリーの少なくとも2倍であることを要求しますが、要件を持たないシステムもあります。一般に、物理メモリーとスワップ空間の両方がほぼいっぱいになっていれば、クラッシュの原因としてメモリー不足を疑ってよいでしょう。
Linuxシステムではカーネルが、未使用の物理メモリーの大部分をファイル・キャッシュに変換する場合があります。追加のメモリーが必要になると、Linuxカーネルはキャッシュ・メモリーをアプリケーションに戻します。この処理はカーネルによって透過的に行われますが、それは、使用可能な物理メモリーがまだ十分存在しても、致命的エラー・ハンドラが報告する未使用物理メモリーの量がゼロに近くなる可能性があることを意味します。
エラー・ログのSYSTEMセクション内の最後の情報はvm_infoで、これはlibjvm.so/jvm.dllに埋め込まれたバージョン文字列です。どのJava VMも一意のvm_info文字列を持ちます。特定のJava VMによって致命的エラー・ログが生成されたのかどうかを疑問に思う場合には、バージョン文字列をチェックしてください。
