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

Один день назад, после нескольких месяцев нормальной работы, наше приложение java начинает периодически вылетать со следующей ошибкой:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (safepoint.cpp:247), pid=2075, tid=140042095163136
#  guarantee(PageArmed == 0) failed: invariant
#
# JRE version: 6.0_23-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 compressed oops)
# An error report file with more information is saved as:
# /var/chat/jSocketer/build/hs_err_pid2075.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

Я посмотрел в hs_err_pid2075.log и увидел, что есть активный поток, который обрабатывает сетевое общение. Однако за последние несколько месяцев не было никаких изменений в приложении или среде. Также не было никакого роста нагрузки. Что я могу сделать, чтобы понять, в чем причина аварии? Существуют ли какие-либо общие шаги для расследования аварии jvm?

UPD http://www.wuala.com/ubear/public

Ответ 1

Авария в JVM, а не во внешнем внутреннем коде. Тем не менее, операция, с которой он разбился, была инициирована и внешней DLL.

Эта строка в файле hs_err_pid описывает операцию, которая разбилась:

VM_Operation (0x00007f5e16e35450): GetAllStackTraces, mode: safepoint, requested by thread 0x0000000040796000

Теперь поток 0x0000000040796000

0x0000000040796000 JavaThread "YJPAgent-Telemetry" daemon [_thread_blocked, id=2115, stack(0x00007f5e16d36000,0x00007f5e16e37000)]

который является потоком, созданным Yourkit. "GetAllStackTraces" - это то, что нужно профайлеру, чтобы сделать выборку. Если вы удалите профилировщик, авария не произойдет.

С этой информацией Невозможно сказать причину сбоя, но вы можете попробовать следующее: Удалить все параметры -XX VM, -verbose: gc и параметры отладочной VM. Они могут помешать интерфейсу профилирования JVM.

Обновление

Код, вызывающий java.lang.Thread#getAllStackTraces() или java.lang.Thread#getStackTrace(), может вызвать тот же самый сбой

Ответ 2

Два раза, когда я наблюдал повторяющиеся сбои JVM, были вызваны аппаратным сбоем, а именно оперативной памятью. Первое, что я попробовал бы запустить утилиту memtest.

Ответ 3

Из отчета об ошибке видно, что вы загрузили агент YourKit. Его телеметрическая нить упоминается как запросчик для операции, которая, похоже, терпит неудачу. Попробуйте запустить приложение без агента YJP, чтобы убедиться, что вы все еще можете воспроизвести сбой.

Как правило, аварии JVM довольно трудно диагностировать. Они могут произойти из-за ошибки в некотором коде JNI или в самой JRE. Если вы подозреваете последнее, возможно, стоит отправить отчет об ошибке в Oracle.

В любом случае, я бы рекомендовал перейти на последнюю версию Java 6, чтобы убедиться, что это не известная проблема, которая уже исправлена, На момент написания этой статьи текущим выпуском является обновление Java 6.

Ответ 4

Если вы не возитесь с чем-либо, что вызвало бы это напрямую (что в основном означает использование собственного кода или библиотек, которые вызывают собственный код), то почти всегда это связано с ошибкой в JVM или аппаратной проблеме.

Если он работает отлично на протяжении веков и теперь начал крутиться, мне кажется, что проблема с оборудованием является наиболее вероятной из двух. Можете ли вы запустить его на другом компьютере, чтобы исключить проблему? Конечно, было бы не повредить обновление до самого последнего обновления Java.

Ответ 5

Переключение на другую версию linux-kernel "исправляет" проблему сокрушения JVM (http://forum.proxmox.com/threads/6998-Best-strategy-to-handle-strange-JVM-errors-inside-VPS?p=40286#post40286). Это помогло мне с моим настоящим сервером. На нем была версия Ubuntu 10.04 LTS OS с версией ядра 2.6.32-33. Поэтому обновление ядра решило эту проблему. JVM больше не терпит краха.