上篇介绍了如何生成一个Java进程的coredump，今天则来总结下当Java进程挂掉之后应该怎么样一步一步来分析。
一、Fatal Error Log
接着昨天的例子继续看，在coredump之后目录里面的文件是这样的：
|
1 2 |
[xxxx@VM_72_32_tlinux ~/fanyy]$ ls core.23687 CoreDumpTest.class CoreDumpTest.h CoreDumpTest.java crash.c crash.so hs_err_pid23687.log |
一般情况下当Java进程挂掉之后，在程序目录下面会生成一个错误日志：hs_err_pidxxxx.log。这个文件是你排查问题的过程中第一个应该阅读的日志，因为这个文件里面会记录很多有用的信息，比如：线程堆栈，堆的使用情况，JVM参数和环境变量，虚拟机状态，操作系统信息等。这里提供的信息非常多，也非常全面，为我们大致定位问题提供了很大的帮助。
先来看下文件开头的注释信息，这里的信息很粗略地指出了崩溃的原因：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f37956cd554, pid=23687, tid=139881182439168 # # JRE version: 6.0_22-b04 # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode linux-amd64 ) # Problematic frame: # C [crash.so+0x554] Java_CoreDumpTest_crash+0x18 # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. |
第8,9行指出了出现问题的栈是在动态库crash.so的Java_CoreDumpTest_crash方法。接下来看下具体的堆栈信息：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
Stack: [0x00007f38a020a000,0x00007f38a030b000], sp=0x00007f38a0309850, free space=3fe0000000000000018k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [crash.so+0x554] Java_CoreDumpTest_crash+0x18 j CoreDumpTest.crash()V+0 j CoreDumpTest.main([Ljava/lang/String;)V+7 v ~StubRoutines::call_stub V [libjvm.so+0x3e75fd] V [libjvm.so+0x5f6fe9] V [libjvm.so+0x3e7435] V [libjvm.so+0x4206d1] V [libjvm.so+0x40eb50] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j CoreDumpTest.crash()V+0 j CoreDumpTest.main([Ljava/lang/String;)V+7 v ~StubRoutines::call_stub |