如何知道JVM因Segfault崩溃的原因? [英] How to know the reason for JVM crashing with Segfault?

查看:89
本文介绍了如何知道JVM因Segfault崩溃的原因?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们看到JVM有时会因segfault而崩溃.我们在日志中看到的唯一错误如下.

We are seeing the JVM getting crashed at times with segfault. The only error we see in logs is as below.

任何人都可以通过查看下面的错误跟踪来提出一些建议.

Anyone can suggest something by looking at the below error trace.

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fef7f1d3eb0, pid=42623, tid=0x00007feea62c8700
#
# JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
# Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# J 62683 C2 org.apache.ignite.internal.marshaller.optimized.OptimizedObjectOutputStream.writeObject0(Ljava/lang/Object;)V (331 bytes) @ 0x00007fef7f1d3eb0 [0x00007fef7f1d3e00+0xb0]
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /tmp/hsperfdata_pvappuser/hs_err_pid42623.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp


在尝试了解导致崩溃的原因时,Oracle JVM文档


While trying to understand the reason for this crash Oracle JVM docs https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/crashes001.html ,this looks to be the case of 5.1.2 Crash in Compiled Code as the problematic frame is java frame(has a "J")

尽管无法获得更多的进展,但我们也不确定何时发布,唯一的问题模式是JVM在星期五(通常在星期五)运行5-6天时出现.我们正在使用在RHEL 6.10上运行的RedHat提供的openjdk-8("1.8.0_232")发行版.

Though could not get much further from it, we also not sure when it comes, the only probale pattern is it comes when JVM is running for 5-6 days so usually on Friday. We are using openjdk-8 ("1.8.0_232") distribution provided by RedHat running on RHEL 6.10.

期待在追踪此错误方面取得领先.

Looking forward to get any leading point in tracing this error.

推荐答案

当前堆栈帧的最后一个调用方法是 writeObject0 .有一个命名约定,即 native 方法的名称以 0 结尾.因此,请检查该方法是否确实是本机的.

The current stack frame has writeObject0 as the last called method. There is a naming convention that native method's names end with 0. Therefore check whether that method is indeed native.

如果是这样,它可能是用C语言编写的,这是一种古老的不安全语言,其程序倾向于以不受控制的方式崩溃.这通常会导致SIGSEGV.

If it is, it is probably written in C, an ancient unsafe language whose programs tend to crash in an uncontrolled way. This often leads to SIGSEGV.

在这种情况下,该方法是用Java编写的.

In this case, that method is written in Java though.

如错误消息中所告知,请阅读hs_err_pid42623.log以获取更多详细信息.在该文件中,您将找到崩溃的代码周围的寄存器和一些机器指令.

As you were told in the error message, read hs_err_pid42623.log for further details. In that file you will find the registers and a few machine instructions around the code that crashed.

这篇关于如何知道JVM因Segfault崩溃的原因?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆