由于SIGSEGV导致的JVM崩溃 [英] JVM Crash due to SIGSEGV

问题描述

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

Our server hung because of a SIGSEGV fault..

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

A fatal error has been detected by the 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

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

I am curious to know what could be the root cause of this?

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

Any help is highly appreciated..Thanks..

推荐答案

信号说明

Signal Description

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

SIGSEGV, SIGBUS, SIGFPE, SIGPIPE, SIGILL -- Used in the implementation for implicit null check, and so forth.

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

SIGQUIT Thread dump support -- To dump Java stack traces at the standard error stream. (Optional.)

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

SIGTERM, SIGINT, SIGHUP -- Used to support the shutdown hook mechanism (java.lang.Runtime.addShutdownHook) when the VM is terminated abnormally. (Optional.)

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

SIGUSR1 -- Used in the implementation of the java.lang.Thread.interrupt method. (Configurable.) Not used starting with Solaris 10 OS. Reserved on Linux. SIGUSR2 Used internally. (Configurable.) Not used starting with Solaris 10 OS. SIGABRT The HotSpot VM does not handle this signal. Instead it calls the abort function after fatal error handling. If an application uses this signal then it should terminate the process to preserve the expected semantics.

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

The fatal error log indicates that the crash was in a native library, there might be a bug in native code or JNI library code. The crash could of course be caused by something else, but analysis of the library and any core file or crash dump is a good starting place.

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

In this case a SIGSEGV occurred with a thread executing in the library libdtagentcore.so . In some cases a bug in a native library manifests itself as a crash in Java VM code. Consider the following crash where a JavaThread fails while in the _thread_in_vm state (meaning that it is executing in Java VM code)

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

• If you get a crash in a native application library (as in your case), then you might be able to attach the native debugger to the core file or crash dump, if it is available. Depending on the operating system, the native debugger is dbx, gdb, or windbg.
• Another approach is to run with the `-Xcheck:jni` option added to the command line. This option is not guaranteed to find all issues with JNI code, but it can help identify a significant number of issues.
• If the native library where the crash occurred is part of the Java runtime environment (for example awt.dll, net.dll, and so forth), then it is possible that you have encountered a library or API bug. If after further analysis you conclude this is a library or API bug, then gather a much data as possible and submit a bug or support call.

这篇关于由于SIGSEGV导致的JVM崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！