前言
最近生产环境的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