JVM由于SIGSEGV崩溃

Question

JVM由于SIGSEGV崩溃

13

我们的服务器由于SIGSEGV故障而挂起。

Java运行时环境检测到了致命错误：

  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

我很好奇这可能是什么根本原因？

非常感谢任何帮助。

- Manisankar

请查看 https://access.redhat.com/solutions/446823。 - laune

这是因为Elastic APM java agent 1.35.0的原因。请参见 https://discuss.elastic.co/t/sigsegv-jvm-crash/322812/1 - Max

3个回答

5

这个错误告诉你，代码从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。

- Steves

3

在JNI代码中有一个棘手的情况：当这样的代码阻止SIGSEGV信号时（例如，因为它阻止了所有信号——这是在线程化的C代码中确保只有主线程处理信号的常见方法），并且它调用“回调”Java虚拟机，则可能导致进程随机地由SIGSEGV触发终止。
实际上并没有什么问题——SIGSEGV实际上是由Java虚拟机触发的，以便检测内存中的某些条件（它充当内存屏障等），并且它期望此类信号将由Java虚拟机处理。不幸的是，当SIGSEGV被阻塞时，“标准”的SIGSEGV反应就会被触发=>VM进程崩溃。

- Ales Teska

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- CodeWalker · Accepted Answer

信号描述

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不处理此信号。取而代之，在致命错误处理后调用abort函数。如果应用程序使用此信号，则应终止进程以保留预期的语义。

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

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

- 如果您在本机应用程序库中获得崩溃（如您的情况），则可以尝试将本机调试器附加到核心文件或崩溃转储，如果可用。根据操作系统，本机调试器是dbx、gdb或windbg。

- 另一种方法是在命令行中添加-Xcheck:jni选项运行。该选项不能保证找到JNI代码的所有问题，但可以帮助识别大量问题。

- 如果崩溃所在的本机库是Java运行时环境的一部分（例如awt.dll，net.dll等），那么可能遇到了库或API错误。如果经过进一步分析，您得出结论这是库或API错误，则尽可能收集数据并提交错误或支持请求。