致命錯誤出現的時候,JVM生成了hs_err_pid<pid>.log這樣的文件,其中每每包含了虛擬機崩潰緣由的重要信息。由於常常遇到,在這篇文章裏,我挑選了一個,而且逐段分析它包含的內容(文件能夠在文章最後下載)。默認狀況下文件是建立在工做目錄下的(若是沒權限建立的話JVM會嘗試把文件寫到/tmp這樣的臨時目錄下面去),固然,文件格式和路徑也能夠經過參數指定,好比: java
1
|
java -XX:ErrorFile=/var/log/java/java_error%p.log
|
這個文件將包括: linux
首先,看到的是對問題的概要介紹: 緩存
1
|
# SIGSEGV (0xb) at pc=0x03568cf4, pid=16819, tid=3073346448
|
一個非預期的錯誤被JRE檢測到,其中: app
若是你對JVM有了解,應該不會對這些東西陌生。 eclipse
接下來是JRE和JVM的版本信息: jvm
1
2
3
|
# JRE version: 6.0_32-b05
# Java VM: Java HotSpot(TM) Server VM (20.7-b02 mixed mode linux-x86 )
|
運行在mixed模式下。 ui
而後是問題幀的信息: spa
1
2
3
|
# Problematic frame:
# C [libgtk-x11-2.0.so.0+0x19fcf4] __float128+0x19fcf4
|
接下去第一部分是線程信息: 操作系統
1
|
Current thread (0x09f30c00): JavaThread"main"[_thread_in_native, id=16822, stack(0xb72a8000,0xb72f9000)]
|
當前線程的: 命令行
1
|
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1(SEGV_MAPERR), si_addr=0x00000010
|
這部分是致使虛擬機終止的非預期的信號信息,含義前面已經大體提到過了。其中si_errno和si_code是Linux下用來鑑別異常的,Windows下是一個ExceptionCode。
1
2
3
|
EAX=0x00000000,EBX=0x0375dd84,ECX=0x00000000,EDX=0x00000000
ESP=0xb72f0fa0,EBP=0xb72f0fb8,ESI=0x00000000,EDI=0x0a6c1800
EIP=0x03568cf4,EFLAGS=0x00010246,CR2=0x00000010
|
這是寄存器上下文。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
Top of Stack: (sp=0xb72f0fa0)
0xb72f0fa0: 00000000004022500040217f 0375dd84
0xb72f0fb0: 000000000a6c1800 b72f0fe8 0356c2c0
0xb72f0fc0: 000000000a6c1800 b72f0fe8 003b3e77
0xb72f0fd0: 003e6c8b 0a1a70d0 0a193358 0375dd84
0xb72f0fe0: 0a276418 0a276418 b72f1048 03536c56
0xb72f0ff0: 0acad000 0b3ca978 0000000c 00dd0674
0xb72f1000: 000000030a2c7d50 b72f1038 0000330c
0xb72f1010: ffffffff ffffffff0000000100000001
Instructions: (pc=0x03568cf4)
0x03568cd4: 8914248975f889d6897d fc89c7 e8 7e 1b
0x03568ce4: ea ff8934248987d4020000e83000ea ff
0x03568cf4: 8b4010893c24c7442408000000008987
0x03568d04: d00200008b838824000089442404e8 dd
|
棧頂程序計數器旁的操做碼,它們能夠被反彙編成系統崩潰前執行的指令。
1
2
3
4
5
6
7
8
9
10
|
Register to memory mapping:
EAX=0x00000000isan unknown value
EBX=0x0375dd84: <offset 0x394d84>in/usr/lib/libgtk-x11-2.0.so.0 at 0x033c9000
ECX=0x00000000isan unknown value
EDX=0x00000000isan unknown value
ESP=0xb72f0fa0ispointing into the stackforthread: 0x09f30c00
EBP=0xb72f0fb8ispointing into the stackforthread: 0x09f30c00
ESI=0x00000000isan unknown value
EDI=0x0a6c1800isan unknown value
|
寄存器和內存映射信息。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
Stack: [0xb72a8000,0xb72f9000], sp=0xb72f0fa0, free space=291k
Native frames: (J=compiled Java code, j=interpreted, Vv=VMcode,C=native code)
C [libgtk-x11-2.0.so.0+0x19fcf4] __float128+0x19fcf4
C [libgtk-x11-2.0.so.0+0x1a32c0] __float128+0xc0
... ...
C [libswt-pi-gtk-3738.so+0x33f6a] Java_org_eclipse_swt_internal_gtk_OS__1Call+0xf
J org.eclipse.swt.internal.gtk.OS._Call(III)I
J org.eclipse.swt.internal.gtk.OS.Call(III)I
Java frames: (J=compiled Java code, j=interpreted, Vv=VMcode)
J org.eclipse.swt.internal.gtk.OS._Call(III)I
J org.eclipse.swt.internal.gtk.OS.Call(III)I
j org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(II)I+5
j org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(II)I+17
v ~StubRoutines::call_stub
... ...
|
線程棧。包含了地址、棧頂、棧計數器和線程還沒有使用的棧信息,因爲棧可能很是長,打印的長度有限制,可是至少本地棧和Java棧都打印出來了(不少時候本地棧打印不出來,可是Java棧通常都能打印出來)。從中能夠看到,Eclipse的虛擬機崩潰了。
1
2
3
4
|
Java Threads: ( => current thread )
0x0b4c1000 JavaThread"Worker-247"[_thread_blocked, id=25417, stack(0x741bc000,0x7420d000)]
0x0a300c00 JavaThread"Worker-246"[_thread_blocked, id=25235, stack(0x7d30c000,0x7d35d000)]
... ...
|
線程信息。一目瞭然,不解釋了。
1
|
VMstate:notat safepoint (normal execution)
|
虛擬機狀態。包括:
1
|
VMMutex/Monitor currently owned by a thread: None
|
虛擬機的Mutex和Monitor目前沒有被線程持有。Mutex是虛擬機內部的鎖,而Monitor則關聯到了Java對象。
1
2
3
4
5
6
7
8
9
|
Heap
PSYoungGen total149056K, used125317K[0xa9700000, 0xb41a0000, 0xb41a0000)
eden space123520K,95% used [0xa9700000,0xb0ac0de0,0xb0fa0000)
from space25536K,26% used [0xb28b0000,0xb2f50748,0xb41a0000)
to space25600K,0% used [0xb0fa0000,0xb0fa0000,0xb28a0000)
PSOldGen total261248K, used239964K[0x941a0000, 0xa40c0000, 0xa9700000)
object space261248K,91% used [0x941a0000,0xa2bf7018,0xa40c0000)
PSPermGen total163328K, used130819K[0x841a0000, 0x8e120000, 0x941a0000)
object space163328K,80% used [0x841a0000,0x8c160c40,0x8e120000)
|
堆信息。新生代、老生代、永久代。對JVM有了解的人應該都清楚,不解釋了。
1
2
|
Code Cache [0xb4262000, 0xb5ac2000, 0xb7262000)
total_blobs=5795nmethods=5534adapters=209free_code_cache=25103616largest_free_block=38336
|
代碼緩存(Code Cache)。這是一塊用於編譯和保存本地代碼的內存,注意是本地代碼,它和PermGen(永久代)是不同的,永久帶是用來存放Java類定義的。
1
2
3
4
5
6
|
Dynamic libraries:
00101000-00122000 r-xp 00000000 08:01 3483560 /usr/lib/libjpeg.so.62.0.0
00122000-00123000 rwxp 00020000 08:01 3483560 /usr/lib/libjpeg.so.62.0.0
00125000-00130000 r-xp 00000000 08:01 9093202 /lib/libgcc_s-4.1.2-20080825.so.1
00130000-00131000 rwxp 0000a000 08:01 9093202 /lib/libgcc_s-4.1.2-20080825.so.1
... ...
|
內存映射。這些信息是虛擬機崩潰時的虛擬內存列表區域。在定位崩潰緣由的時候,它能夠告訴你哪些類庫正在被使用,位置在哪裏,還有堆棧和守護頁信息。就以列表中第一條爲例說明:
每個lib都有兩塊虛擬內存區域——代碼和數據,它們的權限不一樣,代碼區域是r-xp;數據區域是rwxp。守護頁(guard page)由權限爲--xp和rwxp的一對組成。
1
2
3
4
5
6
7
8
|
VMArguments:
jvm_args: -Dosgi.requiredJavaVersion=1.5-XX:MaxPermSize=256m -Xms40m -Xmx512m -Dorg.eclipse.swt.browser.XULRunnerPath=''
java_command: /.../eclipse/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar -os linux -ws gtk -arch x86 -showsplash -launcher /.../eclipse/eclipse -name Eclipse ...
Launcher Type:SUN_STANDARD
Environment Variables:
PATH=...
DISPLAY=:0.0
|
虛擬機參數和環境變量。
1
2
3
4
|
Signal Handlers:
SIGSEGV: [libjvm.so+0x726440], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x726440], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
... ...
|
信號句柄。對於Linux下的信號機制,參閱wiki百科,連接。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
OS:Red Hat Enterprise Linux Client release 5.4 (Tikanga)
uname:Linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:54 EDT 2009 i686
libc:glibc 2.5 NPTL 2.5
rlimit: STACK 10240k, CORE 0k, NPROC 65536, NOFILE 1024, AS infinity
load average:1.78 1.58 1.54
/proc/meminfo:
...
CPU:total 4 (4 cores per cpu, 1 threads per core) family 6 model 42 stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3
/proc/cpuinfo:
...
Memory: 4k page, physical 3631860k(155144k free), swap 5124724k(5056452k free)
|
系統信息。