2009-05-12 4 views
8

Ребята, когда JVM Crashes записывает журнал ошибок hs_err_pid.log. Я хочу узнать, что привело к сбою JVM? Как понять эти журналы, он где-нибудь документирован, как устроен этот журнал. Я пытался найти в сети, но безрезультатно :-(Как понять ошибки Java Hotspot

Указывая соответствующие URL, будут оценены. Спасибо.

ответ

5

Если вы не вызываете машинный код (JNI), ничто в вашем коде не должно когда-нибудь сделать JVM crash, поэтому информация о трассировке стека в этом файле журнала, вероятно, не должна быть очень полезной для большинства разработчиков. Вероятно, поэтому она может быть не документирована (по крайней мере, извне). Так что лучше всего, вероятно, подать отчет об ошибке как указано в сообщении об ошибке.

Но, если вы действительно хотите это понять, у Kohsuke's Blog есть товар. Как обычно. :)

+0

Другие злые вещи могут случиться, что может вызвать сбой виртуальной машины Java. Я видел это с поддержкой файловой системы на одном контроллере, но отдельные точки монтирования. Я видел это при замене существующего файла jar перед остановкой tomcat. (Ой.) Я смог вывести эти две причины из информации в hs_err_pid.log с людьми на форуме Sun Java. –

+0

Я действительно чувствую, что мне нужно это сделать. Мало того, что это просто ссылка на блог, но блог вообще не дает мне никакой информации, которая приносит мне пользу в обнаружении, почему моя программа разбилась. Таким образом, он просто не отвечает на вопрос. :/ – Joehot200

+0

Ссылка теперь мертва. – jdv

0

Для начала найдите самую верхнюю строку, которая выглядит примерно так: «ntdll.dll + 0x2000».

Если точка доступ происходит в вашего машинного кода (т.е. DLL является одним из вас), то выяснить, как убедить свой компилятор, чтобы произвести список отображений из DLL офсетного номера строки. Очевидно, это может означать, что вам нужно повторно запустить с недавно скомпилированной DLL и дождаться, когда проблема возникнет снова.

В противном случае проверьте, что поиск этой конкретной строки вызывает что-то в Google, учитывая, что одна и та же ошибка может означать целый ряд вещей. И посмотрите, похоже ли это имя DLL, это что-то узнаваемое, например. имя драйвера принтера, графический драйвер или какой-либо другой компонент, который вы можете отслеживать для определенного вызова. Независимо от того, что этот компонент, вы можете обновить его до фиксированной версии или избежать вызова. Если вы не уверены в том, что такое компонент, это может быть просто «JVM», который вам нужно обновить - обновление, по крайней мере, до последней версии обновления/младшей версии любой версии, на которой вы находитесь, вероятно, является хорошей идеей.

В прошлом я также видел ошибки в компиляторе JIT, которые могут быть временно решены, сообщая ему не пытаться скомпилировать конкретный метод, о котором идет речь. Как я помню, в этих случаях ошибка hotspot дает некоторые подсказки относительно того, какой метод он был (возможно, только дамп Java-стека), но у меня нет примера, чтобы вспомнить детали.

Смежные вопросы