JVM由于SIGSEGV而崩溃

我们的服务器因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 

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

任何帮助,高度赞赏..谢谢..

Solutions Collecting From Web of "JVM由于SIGSEGV而崩溃"

信号描述

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

SIGQUIT线程转储支持 – 在标准错误流处转储Java堆栈跟踪。 (可选的。)

SIGTERM,SIGINT,SIGHUP – 用于在虚拟机异常终止时支持关闭挂钩机制(java.lang.Runtime.addShutdownHook)。 (可选的。)

SIGUSR1 – 用于java.lang.Thread.interrupt方法的实现。 (可配置)从Solaris 10 OS开始不使用。 在Linux上保留。 SIGUSR2在内部使用。 (可配置)从Solaris 10 OS开始不使用。 SIGABRT HotSpot VM不处理这个信号。 而是在致命的错误处理之后调用中止函数。 如果一个应用程序使用这个信号,那么它应该终止进程来保留预期的语义。

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

在这种情况下,SIGSEGV发生在库libdtagentcore.so中执行的线程中。 在某些情况下,本地库中的一个错误会在Java VM代码中显示为崩溃。 考虑JavaThread在处于_thread_in_vm状态时失败的下列崩溃(这意味着它正在Java VM代码中执行)

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

在JNI代码中有一个很吸引人的情况:当这样的代码阻塞SIGSEGV信号时,例如,因为它阻塞了所有的信号(在线程C代码中很常见的方法是如何确保只有主线程会处理信号) 并且调用“返回”Java VM又名回调),那么它可能导致相当随机的SIGSEGV触发的进程中止。
实际上并没有什么错误–SIGSEGV实际上是由Java VM触发的,以便检测内存中的某些条件(它充当内存屏障等),并期望这种信号将由Java VM处理。 不幸的是,当SIGSEGV被阻塞,那么'标准'SIGSEGV反应被触发=> VM进程崩溃。

它告诉你从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