前言

最近生产环境的JVM老是crash，而用gdb查看call stack的时候，得到的是下面带有一堆问号的,

(gdb) bt
#0  0x00007f635bf98596 in __memmove_avx_unaligned () from /var/lib/jenkins/Projects/libc.so.6
#1  0x00007f634aa1d142 in Unsafe_CopyMemory0 () from /RELEASE/BIN/Linux/_jre/lib/server/libjvm.so
#2  0x00007f63285c20a4 in ?? ()
#3  0x00000000000014ea in ?? ()
#4  0x00000000b5330948 in ?? ()
#5  0x0000000000000000 in ?? ()

这时候，有些人可能就会以为可能symbols 没有匹配，系统库比如libc.so等等缺少debug symbol。而问题也就被搁置了。

实际上我们还有招。

之前也有人在我的另一篇文章 CrackingOysters：两大绝招debug core dump？

提问C#的进程crash怎么办，实际上原理是相同的。在这里以JVM crash为例。

本文主要讲了两点，

使用jhsdb从core dump打印Java的stack trace?
当系统库不匹配，jhsdb不能工作怎么办？

为什么JVM会crash？

JVM crash的原因有很多，有可能是JVM本身自己的bug（这个概率比较小），有可能是自己的程序有问题。

而自己的程序有问题，在自己的程序调用了native的方法的时候，又比较常见。

什么叫调用了native的方法？比如调用了C/C++写的库文件，比如C/C++里面调用JVM。

怎么调用C/C++的库文件，可以通过JNI的方法。这个网上有一堆教程，我试了一下，也很简单。就不在这里赘述。

假设我们有一个Java程序，它调用了C++的库文件，crash了，而用gdb打印call stack的时候是开头的样子，怎么办呢？（用lldb打印call stack也会是一样效果）

JDK本身的调式工具

这时候我们可以通过JDK带有的工具来分析问题。

我发现jhsdb特别好使，它有好多功能，比如可以从core dump里面打印Java 代码调用栈，并告诉你有没有dead lock。

jhsdb的reference是 https:// docs.oracle.com/javase/ 9/tools/jhsdb.htm#
JSWOR-GUID-0345CAEB-71CE-4D71-97FE-AA53A4AB028E

一般会在JAVA_HOME/bin里面。

让我们看看它对自己的描述

它可以是一个命令行的调试器，可以是是一个ui debugger，这两个选项交给感兴趣的读者来探索。

它还支持其他选项: debugd， jstack, jmap, jinfo， jsnap。

这些选项在特定情况下，都很有用，读者可以自己探索一下，这里我主要介绍一下jstack，

它可以打印Java和Native的调用栈，不论是从core dump还是正在运行的process。

这就回到了我们开头的问题，当我们只有core dump的时候，我们可以借助jhsdb jstack来研究程序crash在哪里。

比如我们可以得到类似下面的调用栈

Stack: [0x000070000134c000,0x00007000013cc000],  sp=0x00007000013cbee0,  free space=511k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libHelloWorld.dylib+0x3180]  Book::~Book()+0x30
C  [libHelloWorld.dylib+0x3225]  Book::~Book()+0x15
C  [libsystem_c.dylib+0x5a13c]  __cxa_finalize_ranges+0x13f
C  [libsystem_c.dylib+0x5a412]  exit+0x37
C  [libjli.dylib+0x7dcb]  apple_main+0x5b
C  [libsystem_pthread.dylib+0x6109]  _pthread_start+0x94
C  [libsystem_pthread.dylib+0x1b8b]  thread_start+0xf

系统库不匹配

jhsdb很好使，但是有时候却有心无力。

为什么呢？

因为有时候我们的程序crash的机器时客户的机器，而我们手头没有任何机器跟客户的机器一样。

有时候更致命的是，我们无法得知客户的具体机器类型，也就是无法知道客户的系统库版本。

而jhsdb在系统库不匹配的时候，会拒绝工作，得到下面的错误，

Error attaching to core file: Can't attach to the core file
sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the core file
        at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Native Method)
        at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(LinuxDebuggerLocal.java:282)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:674)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux(HotSpotAgent.java:612)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:338)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:305)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:157)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:191)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:297)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:533)

这时候怎么办呢？

最好的办法是跟客户沟通，让客户告诉我们他们安装的系统库版本，装了什么补丁，这样我们可以从网上下载对应的系统库到我们的机器，然后通过设置SA_ROOT来是jhsdb使用下载的系统库。

这时候jhsdb就会正常工作。

如果实在无法获取正确的系统库版本，这时候还有一个办法。那就是使用gdb来debug jhsdb，在对应报错的地方做一些hack，这样jhsdb就可以正常工作了。

这个办法涉及到如何调试jhsdb的技巧，实际使用的时机不多，略过。

原文链接：
tuicool.com/articles/BRFVBrf

里克资源网

JVM crash了，怎么办

前言

为什么JVM会crash？

JDK本身的调式工具

系统库不匹配