java core dump分析实战

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