Question

我们的服务器因SIGSEGV故障而挂起..

Java Runtime Environment检测到致命错误：

  SIGSEGV (0xb) at pc=0x00007ff5c7195aaa, pid=262778, tid=140690480097024

 JRE version: 6.0_35-b10
 Java VM: Java HotSpot(TM) 64-Bit Server VM (20.10-b01 mixed mode linux-amd64 compressed oops)
 Problematic frame:
 C  [libdtagentcore.so+0xb7aaa]  long double restrict+0x506f6

我很想知道这可能是什么原因？

任何帮助都非常感谢。谢谢..

Answer 1

信号说明

SIGSEGV，SIGBUS，SIGFPE，SIGPIPE，SIGILL -   用于隐式空检查的实现，等等。


SIGQUIT线程转储支持 - 在标准错误流中转储Java堆栈跟踪。（可选）


SIGTERM，SIGINT，SIGHUP - 用于在VM异常终止时支持关闭挂钩机制（java.lang.Runtime.addShutdownHook）。（可选）


SIGUSR1 - 用于实现java.lang.Thread.interrupt方法。（可配置。）从Solaris 10 OS开始不使用。在Linux上保留。   SIGUSR2内部使用。（可配置。）从Solaris 10 OS开始不使用。   SIGABRT HotSpot VM无法处理此信号。相反，它会在致命错误处理后调用中止函数。如果应用程序使用此信号，那么它应该终止进程以保留预期的语义。

致命错误日志表明崩溃是在本机库中，本机代码或JNI库代码中可能存在错误。崩溃当然可能是由其他原因引起的，但对库和任何核心文件或崩溃转储的分析是一个很好的起点。

在这种情况下，SIGrEGV与库libdtagentcore.so中执行的线程一起发生。在某些情况下，本机库中的错误表现为Java VM代码中的崩溃。考虑以下崩溃，其中JavaThread在_thread_in_vm状态下失败（意味着它在Java VM代码中执行）

如果您在本机应用程序库中遇到崩溃（如您的情况），那么您可以将本机调试器附加到核心文件或崩溃转储（如果可用）。根据操作系统，本机调试器是dbx，gdb或windbg。
另一种方法是在命令行中添加`-Xcheck：jni`选项。此选项无法保证找到JNI代码的所有问题，但它可以帮助识别大量问题。
如果发生崩溃的本机库是Java运行时环境的一部分（例如awt.dll，net.dll等），那么您可能遇到过库或API错误。如果经过进一步分析后得出结论，这是一个库或API错误，那么收集尽可能多的数据并提交错误或支持调用。

Answer 2

它告诉您从libdtagentcore.so加载的代码中发生错误。更具体地说，它发生在名为restrict的函数和偏移0x506f6的函数中。提到的第一个偏移量（0xb7aaa）在库本身内偏移。如果它是使用调试符号（-g）构建的，那么您可以在Linux上查看导致异常的代码：

addr2line -e libdtagentcore.so -C -f 0xb7aaa

如果有人在Windows上阅读，请参阅https://community.oracle.com/blogs/kohsuke/2009/02/19/crash-course-jvm-crash-analysis

https://www.youtube.com/watch?v=jd6dJa7tSNU

中的更多详情

Answer 3

JNI代码中有一个引人注目的情况：当这样的代码阻塞SIGSEGV信号时，例如因为它阻止了所有信号（在线程C代码中非常常见的方法如何确保只有主线程处理信号） AND 它调用＆＃39; back＆＃39; Java VM（也就是回调）然后它可以导致相当随机的SIGSEGV触发的流程中止并且几乎没有任何错误 - SIGSEGV实际上是由Java VM触发的，以便检测内存中的某些条件（它充当内存屏障......等），并且它期望这样的信号将由Java VM处理。不幸的是，当SIGSEGV被阻止时，那么标准＆＃39; SIGSEGV反应被触发=＆gt; VM进程崩溃。

由于SIGSEGV导致的JVM崩溃

3 个答案: