Как узнать причину сбоя JVM с Segfault? - PullRequest
Новая
       105

Как узнать причину сбоя JVM с Segfault?

0 голосов
/ 21 января 2020

Мы видим, что JVM иногда падает из-за segfault. Единственная ошибка, которую мы видим в журналах, как показано ниже.

Любой может предложить что-то, посмотрев на приведенную ниже трассировку ошибок. 

# 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

При попытке понять причину для этого cra sh Oracle документов JVM https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/crashes001.html это выглядит как случай 5.1.2 Cra sh в скомпилированном коде, поскольку проблемный кадр c составляет java кадр (имеет букву "J")

Хотя от него не получилось гораздо дальше, мы также не уверены, когда это произойдет, единственная вероятностная модель - это то, что JVM работает в течение 5-6 дней, обычно в пятницу , Мы используем дистрибутив openjdk-8 ("1.8.0_232"), предоставленный RedHat на RHEL 6.10.

Будем рады получить какую-либо передовую точку в отслеживании этой ошибки.

1 Ответ

0 голосов
/ 21 января 2020

Текущий кадр стека имеет writeObject0 в качестве последнего вызванного метода. Существует соглашение об именах, согласно которому имена native методов заканчиваются на 0. Поэтому проверьте, действительно ли этот метод является нативным.

Если это так, он, вероятно, написан на C, древнем небезопасном языке, программы которого имеют тенденцию к взлому sh неконтролируемым образом. Это часто приводит к SIGSEGV.

В этом случае этот метод записан в Java.

Как вам сказали в сообщении об ошибке, прочитайте hs_err_pid42623.log для получения дополнительной информации. В этом файле вы найдете регистры и несколько машинных инструкций по коду, который вышел из строя.

...