JVM 崩溃原因排查

主要需要找到 格式一般是 hs_err_pid<pid>.log，一般在 jvm 的工作目录中，如果你在工作目录里看到了这个日志，说明 jvm 崩溃过
实际的文件的例子：[[hs_err_pid16633.log]]
如何查看崩溃日志，参考博客：
JVM 崩溃 - kelelipeng - 博客园
JVM 致命错误日志 (hs_err_pid.log) 分析-腾讯云开发者社区-腾讯云

其实日志的一开头在 Problematic frame 中就告诉了你哪里导致的 JVM 崩溃

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fce18d61aec, pid=16633, tid=0x00007fcd605ee700
#
# JRE version: OpenJDK Runtime Environment (8.0_362-b08) (build 1.8.0_362-b08)
# Java VM: OpenJDK 64-Bit Server VM (25.362-b08 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libc.so.6+0x85aec]  cfree+0x1c
#
# Core dump written. Default location: /opt/dms/dms-DataAggregation-all/core or core.16633
#
# If you would like to submit a bug report, please visit:
#   https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207&component=java-1.8.0-openjdk
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

然后我们可以到

---------------  T H R E A D  ---------------

这部分下面去找具体是哪个栈？有可能是本地调用栈，也有可能是虚拟机栈，总之，定位到了栈，就总能找到问题。
我们当时遇到的这个问题，碰到的是 TDengine 的一个 libtaos.so 崩溃的问题，想了好多办法都没有解决，最后升级了 TDengine 才解决。
如果是 Java 栈，那就是代码的问题，如果是 lib.so 文件，那基本上就只能查文档了，实在不行就只能重启或者升级软件了，这已经不是代码层面的问题了