javacoredump分析實戰

xpbob發表於2018-06-10
Java

hs_err_pid簡介

hs_err_pid<pid>.log是java程式發生core的時候產生的檔案，裡面有當時出錯時jvm的執行情況。

排查方法

標頭檔案解讀可以檢視問題

標頭檔案包含了簡單的資訊闡述，裡面就core掉的原因

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x69ba3a96, pid=376, tid=1848
#
# Java VM: Java HotSpot(TM) Client VM (11.0-b16 mixed mode, sharing windows-x86)
# Problematic frame:
# C  [nvoglnt.dll+0x6a3a96]
#

這裡的問題是動態庫的呼叫，這個庫如果不是java自帶的庫，而是第三方的庫，那麼可以檢視這個庫是否和機型系統想匹配，如果不匹配換匹配的庫就好，如果匹配，需要重新安裝該庫嘗試。

#
#  Out of Memory Error (os_linux_x86.cpp:718), pid=29229, tid=140505843455744
#
# JRE version: Java(TM) SE Runtime Environment (7.0_67-b01) (build 1.7.0_67-b01)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.65-b04 mixed mode linux-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#

這裡直接指出了問題的原因是oom，後面還會有實體記憶體狀態，可以用來印證這個錯誤。

標頭檔案+棧資訊

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x009fcf52, pid=4344, tid=5876
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_14-b03 mixed mode)
# Problematic frame:
# V  [jvm.dll+0x9cf52]
#

標頭檔案資訊告訴我們是jvm.dll這個是jvm自己的庫。此時就不能單純的依靠這個資訊來換庫解決。
必須看棧資訊，一般會有兩個模組，一個是Native frames一個是Java frames。

Stack: [0x00030000,0x00070000),  sp=0x0006f934,  free space=254k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x9cf52]
C  [NativeCode.dll+0x148b]
C  [NativeCode.dll+0x1253]
j  com.sy.test.TestNative.sayHello()V+0
j  com.sy.test.TestNative.main([Ljava/lang/String;)V+22
v  ~StubRoutines::call_stub
V  [jvm.dll+0x875dd]
V  [jvm.dll+0xdfd96]
V  [jvm.dll+0x874ae]
V  [jvm.dll+0x8e6f1]
C  [javaw.exe+0x14c5]
C  [javaw.exe+0x3151]
C  [kernel32.dll+0x16fd7]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.sy.test.TestNative.sayHello()V+0
j  com.sy.test.TestNative.main([Ljava/lang/String;)V+22
v  ~StubRoutines::call_stub

上面的資訊，是從java呼叫到c了，極大的可能是jni的形式，此時需要檢視，後面的PATH,LD_LIBRARY_PATH,以及-Djava.library.path檢視是否編寫了JNI。

場景問題

80%的問題上面的方法都可以推斷和解決，下面說說20%的情況

jit問題表徵

# JRE version: Java(TM) SE Runtime Environment (8.0_25-b17) (build 1.8.0_25-b17)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.25-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  0x0000000764928700
Stack: [0x00002b9213782000,0x00002b9213803000],  sp=0x00002b92137fe6d0,  free space=497k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x0000000764928700

這種直接就是問題都是暫存器地址的，也沒有棧資訊的，基本問題在JIT

# Problematic frame:
# J org.apache.http.impl.cookie.BestMatchSpec.formatCookies(Ljava/util/List;)Ljava/util/List;

上面這種造成core的是java程式碼引起的，是直譯器的問題，基本問題在JIT

純jvm程式碼

# JRE version: 6.0_45-b06
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.45-b01 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# v  ~StubRoutines::jshort_disjoint_arraycopy

Stack: [0x00007fecfc9dc000,0x00007fecfca1d000],  sp=0x00007fecfca1b4b0,  free space=253k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
v  ~StubRoutines::jshort_disjoint_arraycopy

上圖整體的資訊都是jvm的程式碼，這種情況一般是jvm的bug，可以查jvm的bug列表並且更換jdk

引用案例出處
http://bbs.csdn.net/topics/390975171
http://blog.csdn.net/zct08/article/details/6333467
http://m635674608.iteye.com/blog/2257650


相關文章