Среда выполнения Java обнаружила фатальную ошибку, как ее устранить

Обновлено: 04.07.2024

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

Заголовок журнала ошибок указывает тип ошибки и проблемный кадр, а стек потоков указывает текущий поток и трассировку стека. См. Формат заголовка.

Следующие возможные причины сбоя.

5.1.1 Сбой в собственном коде

Если в журнале неустранимых ошибок указано, что проблемный фрейм является собственной библиотекой, это может быть ошибка в собственном коде или коде библиотеки Java Native Interface (JNI). Сбой, конечно, может быть вызван чем-то другим, но хорошей отправной точкой будет анализ библиотеки и любого файла ядра или аварийного дампа. Рассмотрим отрывок в примере 5-1 из заголовка журнала неустранимых ошибок.

Пример 5-1. Выдержка из заголовка журнала неустранимых ошибок

В этом случае SIGSEGV возник при выполнении потока в библиотеке libApplication.so .

В некоторых случаях ошибка в собственной библиотеке проявляется как сбой в коде Java VM. Рассмотрим сбой в примере 5-2, когда происходит сбой JavaThread в состоянии _thread_in_vm (это означает, что он выполняется в коде Java VM).

Пример 5-2 Пример сбоя

В этом случае, несмотря на то, что проблемный кадр является кадром виртуальной машины, стек потоков показывает, что собственная процедура в App.dll вызвала виртуальную машину (вероятно, с помощью JNI).

Первый шаг к устранению сбоя в нативной библиотеке – исследование источника нативной библиотеки, в котором произошел сбой.

Если нативная библиотека предоставляется вашим приложением, изучите исходный код вашей нативной библиотеки. Значительное количество проблем с кодом JNI можно определить, запустив приложение с опцией -Xcheck:jni, добавленной в командную строку. См. параметр -Xcheck:jni.

Если собственная библиотека была предоставлена ​​другим поставщиком и используется вашим приложением, отправьте отчет об ошибке в этом стороннем приложении и предоставьте информацию из журнала неустранимых ошибок.

Если собственная библиотека, в которой произошел сбой, является частью среды выполнения Java (JRE) (например, awt.dll, net.dll и т. д.), возможно, вы столкнулись с ошибкой библиотеки или API. . Если это так, соберите как можно больше данных и отправьте сообщение об ошибке или отчет, указав имя библиотеки. Библиотеки JRE можно найти в каталогах jre/lib или jre/bin дистрибутива JRE. См. раздел «Отправить отчет об ошибке».

Вы можете устранить сбой в собственной библиотеке приложений, подключив собственный отладчик к основному файлу или аварийному дампу, если он доступен. В зависимости от ОС родной отладчик — dbx, gdb или windbg. См. Собственные инструменты операционной системы.

5.1.2 Сбой в скомпилированном коде

Если в журнале неустранимых ошибок указано, что сбой произошел в скомпилированном коде, возможно, вы столкнулись с ошибкой компилятора, которая привела к неправильной генерации кода. Вы можете распознать сбой в скомпилированном коде, если тип проблемного фрейма — J (что означает скомпилированный фрейм Java). В примере 5-3 показан такой сбой.

Пример 5-3. Сбой в скомпилированном коде

Примечание. Полный стек потоков недоступен. Выходная строка «произошла ошибка во время сообщения об ошибке» означает, что возникла проблема при попытке получить трассировку стека (это может указывать на повреждение стека).

Можно временно обойти проблему, переключив компилятор (например, используя виртуальную машину клиента HotSpot вместо виртуальной машины сервера HotSpot или наоборот) или исключив из компиляции метод, вызвавший сбой. В этом конкретном примере может быть невозможно переключить компилятор, поскольку он был взят с 64-разрядной виртуальной машины сервера, и, следовательно, может быть невозможно переключиться на 32-разрядную клиентскую виртуальную машину.

5.1.3 Сбой в потоке компилятора HotSpot

Если выходные данные журнала неустранимых ошибок показывают, что текущим потоком является JavaThread с именем CompilerThread0 , CompilerThread1 или AdapterCompiler , возможно, вы столкнулись с ошибкой компилятора. В этом случае может возникнуть необходимость временно обойти проблему, переключив компилятор (например, используя клиентскую виртуальную машину HotSpot вместо виртуальной машины HotSpot Server или наоборот), или исключив из компиляции метод, спровоцировавший сбой. .

5.1.4 Сбой в потоке ВМ

Если вывод журнала неустранимых ошибок показывает, что текущим потоком является VMThread , найдите строку, содержащую VM_Operation, в разделе THREAD. VMThread — это специальный поток в виртуальной машине HotSpot. Он выполняет специальные задачи в виртуальной машине, такие как сборка мусора (GC). Если VM_Operation предполагает, что операция является сборщиком мусора, возможно, вы столкнулись с такой проблемой, как повреждение кучи.

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

Дополнительную информацию о возможных обходных путях см. в разделе Обработка сбоев во время сборки мусора.

5.1.5 Сбой из-за переполнения стека

Переполнение стека в коде языка Java обычно приводит к тому, что нарушающий поток выдает исключение java.lang.StackOverflowError. С другой стороны, C и C++ пишут за конец стека и вызывают переполнение стека. Это фатальная ошибка, которая приводит к завершению процесса.

В реализации HotSpot методы Java совместно используют кадры стека с собственным кодом C/C++, а именно собственным кодом пользователя и самой виртуальной машиной. Методы Java генерируют код, который проверяет, доступно ли пространство стека на фиксированном расстоянии от конца стека, чтобы можно было вызывать собственный код, не выходя за пределы стека. Это расстояние до конца стопки называется «теневыми страницами». Размер теневых страниц составляет от 3 до 20 страниц в зависимости от платформы. Это расстояние настраивается, поэтому приложения с собственным кодом, требующие большего расстояния, чем расстояние по умолчанию, могут увеличить размер теневой страницы. Параметр увеличения количества теневых страниц: -XX:StackShadowPages= n , где n больше, чем теневые страницы стека по умолчанию для платформы.

Если ваше приложение получает ошибку сегментации без основного файла или файла журнала неустранимых ошибок, см. Приложение A, или STACK_OVERFLOW_ERROR в Windows, или сообщение "Произошло неустранимое переполнение стека", это указывает на превышение значения StackShadowPages. и требуется больше места.

Если вы увеличиваете значение StackShadowPages , вам также может потребоваться увеличить размер стека потоков по умолчанию с помощью параметра -Xss. Увеличение размера стека потоков по умолчанию может уменьшить количество создаваемых потоков, поэтому будьте осторожны при выборе значения размера стека потоков. Размер стека потоков варьируется в зависимости от платформы от 256 КБ до 1024 КБ.

Пример 5-4 Исключение переполнения стека

Вы можете интерпретировать следующую информацию из примера 5-4.

Исключение: EXCEPTION_STACK_OVERFLOW .

Состояние потока — _thread_in_native, что означает, что поток выполняет собственный код или код JNI.

В информации о стеке свободного места всего 4 КБ (одна страница в системе Windows). Кроме того, указатель стека ( sp ) находится по адресу 0x00041000 , что близко к концу стека по адресу 0x00040000 .

Распечатка нативных фреймов показывает, что в данном случае проблема заключается в рекурсивной нативной функции. Выходное обозначение. . указывает, что дополнительные кадры существуют, но не были напечатаны. Вывод ограничен 100 кадрами.

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

Заголовок журнала ошибок указывает тип ошибки и проблемный кадр, а стек потоков указывает текущий поток и трассировку стека. См. Формат заголовка.

Следующие возможные причины сбоя.

5.1.1 Сбой в собственном коде

Если в журнале неустранимых ошибок указано, что проблемный фрейм является собственной библиотекой, это может быть ошибка в собственном коде или коде библиотеки Java Native Interface (JNI). Сбой, конечно, может быть вызван чем-то другим, но хорошей отправной точкой будет анализ библиотеки и любого файла ядра или аварийного дампа. Рассмотрим отрывок в примере 5-1 из заголовка журнала неустранимых ошибок.

Пример 5-1. Выдержка из заголовка журнала неустранимых ошибок

В этом случае SIGSEGV возник при выполнении потока в библиотеке libApplication.so .

В некоторых случаях ошибка в собственной библиотеке проявляется как сбой в коде Java VM. Рассмотрим сбой в примере 5-2, когда происходит сбой JavaThread в состоянии _thread_in_vm (это означает, что он выполняется в коде Java VM).

Пример 5-2 Пример сбоя

В этом случае, несмотря на то, что проблемный кадр является кадром виртуальной машины, стек потоков показывает, что собственная процедура в App.dll вызвала виртуальную машину (вероятно, с помощью JNI).

Первый шаг к устранению сбоя в нативной библиотеке – исследование источника нативной библиотеки, в котором произошел сбой.

Если нативная библиотека предоставляется вашим приложением, изучите исходный код вашей нативной библиотеки. Значительное количество проблем с кодом JNI можно определить, запустив приложение с опцией -Xcheck:jni, добавленной в командную строку. См. параметр -Xcheck:jni.

Если собственная библиотека была предоставлена ​​другим поставщиком и используется вашим приложением, отправьте отчет об ошибке в этом стороннем приложении и предоставьте информацию из журнала неустранимых ошибок.

Если собственная библиотека, в которой произошел сбой, является частью среды выполнения Java (JRE) (например, awt.dll, net.dll и т. д.), возможно, вы столкнулись с ошибкой библиотеки или API. . Если это так, соберите как можно больше данных и отправьте сообщение об ошибке или отчет, указав имя библиотеки. Библиотеки JRE можно найти в каталогах jre/lib или jre/bin дистрибутива JRE. См. раздел «Отправить отчет об ошибке».

Вы можете устранить сбой в собственной библиотеке приложений, подключив собственный отладчик к основному файлу или аварийному дампу, если он доступен. В зависимости от ОС родной отладчик — dbx, gdb или windbg. См. Собственные инструменты операционной системы.

5.1.2 Сбой в скомпилированном коде

Если в журнале неустранимых ошибок указано, что сбой произошел в скомпилированном коде, возможно, вы столкнулись с ошибкой компилятора, которая привела к неправильной генерации кода. Вы можете распознать сбой в скомпилированном коде, если тип проблемного фрейма — J (что означает скомпилированный фрейм Java). В примере 5-3 показан такой сбой.

Пример 5-3. Сбой в скомпилированном коде

Примечание. Полный стек потоков недоступен. Выходная строка «произошла ошибка во время сообщения об ошибке» означает, что возникла проблема при попытке получить трассировку стека (это может указывать на повреждение стека).

Можно временно обойти проблему, переключив компилятор (например, используя виртуальную машину клиента HotSpot вместо виртуальной машины сервера HotSpot или наоборот) или исключив из компиляции метод, вызвавший сбой. В этом конкретном примере может быть невозможно переключить компилятор, поскольку он был взят с 64-разрядной виртуальной машины сервера, и, следовательно, может быть невозможно переключиться на 32-разрядную клиентскую виртуальную машину.

5.1.3 Сбой в потоке компилятора HotSpot

Если выходные данные журнала неустранимых ошибок показывают, что текущим потоком является JavaThread с именем CompilerThread0 , CompilerThread1 или AdapterCompiler , возможно, вы столкнулись с ошибкой компилятора. В этом случае может возникнуть необходимость временно обойти проблему, переключив компилятор (например, используя клиентскую виртуальную машину HotSpot вместо виртуальной машины HotSpot Server или наоборот), или исключив из компиляции метод, спровоцировавший сбой. .

5.1.4 Сбой в потоке ВМ

Если вывод журнала неустранимых ошибок показывает, что текущим потоком является VMThread , найдите строку, содержащую VM_Operation, в разделе THREAD. VMThread — это специальный поток в виртуальной машине HotSpot. Он выполняет специальные задачи в виртуальной машине, такие как сборка мусора (GC). Если VM_Operation предполагает, что операция является сборщиком мусора, возможно, вы столкнулись с такой проблемой, как повреждение кучи.

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

Дополнительную информацию о возможных обходных путях см. в разделе Обработка сбоев во время сборки мусора.

5.1.5 Сбой из-за переполнения стека

Переполнение стека в коде языка Java обычно приводит к тому, что нарушающий поток выдает исключение java.lang.StackOverflowError. С другой стороны, C и C++ пишут за конец стека и вызывают переполнение стека. Это фатальная ошибка, которая приводит к завершению процесса.

В реализации HotSpot методы Java совместно используют кадры стека с собственным кодом C/C++, а именно собственным кодом пользователя и самой виртуальной машиной. Методы Java генерируют код, который проверяет, доступно ли пространство стека на фиксированном расстоянии от конца стека, чтобы можно было вызывать собственный код, не выходя за пределы стека. Это расстояние до конца стопки называется «теневыми страницами». Размер теневых страниц составляет от 3 до 20 страниц в зависимости от платформы. Это расстояние настраивается, поэтому приложения с собственным кодом, требующие большего расстояния, чем расстояние по умолчанию, могут увеличить размер теневой страницы. Параметр увеличения количества теневых страниц: -XX:StackShadowPages= n , где n больше, чем теневые страницы стека по умолчанию для платформы.

Если ваше приложение получает ошибку сегментации без основного файла или файла журнала неустранимых ошибок, см. Приложение A, или STACK_OVERFLOW_ERROR в Windows, или сообщение "Произошло неустранимое переполнение стека", это указывает на превышение значения StackShadowPages. и требуется больше места.

Если вы увеличиваете значение StackShadowPages , вам также может потребоваться увеличить размер стека потоков по умолчанию с помощью параметра -Xss.Увеличение размера стека потоков по умолчанию может уменьшить количество создаваемых потоков, поэтому будьте осторожны при выборе значения размера стека потоков. Размер стека потоков варьируется в зависимости от платформы от 256 КБ до 1024 КБ.

Пример 5-4 Исключение переполнения стека

Вы можете интерпретировать следующую информацию из примера 5-4.

Исключение: EXCEPTION_STACK_OVERFLOW .

Состояние потока — _thread_in_native, что означает, что поток выполняет собственный код или код JNI.

В информации о стеке свободного места всего 4 КБ (одна страница в системе Windows). Кроме того, указатель стека ( sp ) находится по адресу 0x00041000 , что близко к концу стека по адресу 0x00040000 .

Распечатка нативных фреймов показывает, что в данном случае проблема заключается в рекурсивной нативной функции. Выходное обозначение. . указывает, что дополнительные кадры существуют, но не были напечатаны. Вывод ограничен 100 кадрами.

Я думаю, что ошибка возникает внутри библиотеки DirectX.

Попробуйте переустановить графический драйвер.

Отключите утилиты видеокарты.

Установите переменную среды J2D_D3D=false.

Ангус Фергюсон написал: Я думаю, что ошибка происходит внутри библиотеки DirectX.

Попробуйте переустановить графический драйвер.

Отключите утилиты видеокарты.

Установите переменную среды J2D_D3D=false.

У меня есть только встроенное видео, и я несколько раз переустанавливал драйверы (переформатировал компьютер + новые драйверы).
Не знаю, как отключить утилиты видеокарты.
и понятия не имею, как установить J2D_D3D=false. извините, не мудрить с java и переменными.


У меня была эта проблема в течение длительного времени, когда я пытался запустить сервер Lineage 2 L2J и искал решение в течение многих лет. иногда это происходит, когда я открываю сервер, а иногда он ждет 2-3-4 часа и работает отлично, тогда я получаю эту ошибку.
Никто в сообществе l2j даже не видел эту ошибку (по крайней мере, они так говорят) и пытался использовать множество способов, чтобы помочь мне исправить ее, и она всегда возвращается. та же ошибка
Пожалуйста, если кто-нибудь видел это или знает, или надежное исправление, я все уши. любой вклад помогает, я попытаюсь сделать другие вещи, которые вы упомянули, Ангус, спасибо (если я смогу понять, как ;-)


Маршал

Кейси Кандо написал: и понятия не имею, как установить J2D_D3D=false. извините, не мудрить с java и переменными.

Измените команду, которая запускает вашу игру, чтобы она выглядела следующим образом:

где "." - это то, что у вас уже есть.


Не уверен, что это то, о чем вы говорите. но я открываю пакетный файл Windows для запуска сервера, и это то, что находится внутри пакетного файла.

@echo off
название Game Server Console

:start
echo Запуск игрового сервера L2J.
эхо.

java -Xms512m -Xmx2g -jar l2jserver.jar

если ERRORLEVEL 2 перейти к перезагрузке
если ERRORLEVEL 1 перейти к ошибке
перейти к концу

: перезапустить
echo.
Echo Admin перезапустил игровой сервер.
эхо.
перейти к началу

: ошибка
эхо.
Игровой сервер echo аварийно закрыт!
эхо.

:конец
эхо.
Игровой сервер echo прекращен.
эхо.
пауза

Еще раз извините за нубство. я пытаюсь научиться этому без учителя


Маршал

Да, именно об этом я и говорю. К счастью, он находится в пакетном файле, так что вы можете редактировать строку, начинающуюся с «java». Надеюсь, она не доступна только для чтения или что-то в этом роде.


добавить это в строку или удалить все и добавить только это?
извините. не могли бы вы показать мне, как это должно выглядеть.
нравится это?

@echo off
название Game Server Console

:start
echo Запуск игрового сервера L2J.
эхо.

java -DJ2D_D3D=false -Xms512m -Xmx2g -jar l2jserver.jar

если ERRORLEVEL 2 перейти к перезагрузке
если ERRORLEVEL 1 перейти к ошибке
перейти к концу

: перезапустить
echo.
Echo Admin перезапустил игровой сервер.
эхо.
перейти к началу

: ошибка
эхо.
Игровой сервер echo аварийно закрыт!
эхо.

:конец
эхо.
Игровой сервер echo прекращен.
эхо.
пауза

(в свойствах файла bat не сказано, что он только для чтения)
и мне нужно только отредактировать эту строку и попытаться запустить сервер. мне не нужно вставлять что-то в окружение?


Маршал

Да, вот как это сделать.Похоже, Ангус знает, о чем говорит, и надеюсь, что это решит вашу проблему.


только что попробовал, не загружается

Игровой сервер аварийно закрыт!

Я пытался решить эту проблему с Java 8. 2 года назад
я использовал все Java и одну и ту же ошибку,
если кто-то думает, что может решить эту проблему вручную. Я хочу, чтобы вы
добавили меня в скайп: macomb420@gmail
и вы можете направить меня на демонстрацию экрана, или мы можем сделать Team Viewer по вашему выбору.
Я просто готов сделать все, что нужно, чтобы исправить это, пожалуйста

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

Содержит ли файл журнала дополнительную информацию?

Вы должны выяснить, что происходило в момент возникновения ошибки.

Да, это дает мне полный файл журнала ошибок, но я не могу опубликовать его здесь. ко многим ключевым словам, которые не будут работать на этих форумах
я получил новый жесткий диск и новую версию Windows 10, переустановил все, и я все еще получаю сообщение об ошибке
я использую mysql8.0+ / navicat 12+ / ЖДК 12+. это единственные 3 вещи, которые у меня есть на моем компьютере и + файлы сервера
я пробовал каждую версию каждой программы и все та же ошибка. это должна быть настройка или что-то в этом роде.
Пожалуйста, кто-нибудь. кто может помочь. я дам полный доступ к моему компьютеру любому, кто может исправить или думает, что может решить эту проблему.
Я не могу опубликовать файл журнала здесь, если кто-нибудь знает сайт, я могу сообщить мне, и я опубликую здесь полный файл журнала

[Миниатюра для Screenshot_1.jpg]

[Миниатюра для Screenshot_2.jpg]

[Миниатюра для Screenshot_3.jpg]

[Миниатюра для Screenshot_4.jpg]

[Миниатюра для Screenshot_5.jpg]

[Миниатюра для Screenshot_6.jpg]

[Миниатюра для Screenshot_7.jpg]

[Миниатюра для Screenshot_8.jpg]

[Миниатюра для Screenshot_9.jpg]

[Миниатюра для Screenshot_10.jpg]

После быстрого поиска позвольте мне немного рассказать тем, кто не разбирается в этом:

Поскольку я не смог найти вариант загрузки, я не смог протестировать файлы самостоятельно, но: поскольку большинство "частных серверов" требуют модификации клиента, а большинство "разработчиков" этих "сообществ" не хотят "детских скриптов" чтобы понять, как это делается, в этом обычно используется обфускация. Моим главным предположением здесь была бы обфускация, используемая для файлов, которые OP пытается использовать, как-то уродует jvm, который в основном терпит неудачу из-за сообщения о нарушении доступа - в unix это чаще всего ошибка страницы - во всяком случае по той же причине: из-за неправильных кодов операций, вызванных обфускация знаменитая арифметика указателя C идет не так, как надо, и заставляет jvm пытаться получить доступ к памяти не в пространстве процесса. Также Minecraft известен этим, поскольку Mojang (теперь M$) использует обфускацию для защиты от простой декомпиляции, чтобы затруднить разработку «взломанных клиентов», позволяющих играть в игру без оплаты. Однажды я попробовал «очищенную» версию, в которой кто-то приложил усилия и попытался исправить большинство вещей после деобфускации с помощью общедоступного пакета кодеров Minecraft — еще хуже — но, скорее всего, из-за большего количества ошибок в базовом движке LWJGL.

В чем причина ошибки jvm, скорее всего, jvm, os и/или аппаратное обеспечение, используемое OP, несовместимо с server.jar OP, который хочет запустить. Лучшая попытка: используйте другое оборудование и, если возможно, базовый дистрибутив Linux вместо Windows, поэтому используйте openJDK. В противном случае: играйте в оригинальную Lineage2 — игра бесплатна.

это не просочившиеся файлы. ncsoft позволяет открывать на основе более старых версий игры, чтобы люди могли создавать и играть
если вы хотите увидеть, с чем я работаю, или проверить это самостоятельно, я могу дать несколько ссылок на частные серверные файлы проектов с много разработчиков работают над одним проектом.
Я хочу сказать, что многие люди используют эти серверы, и это первый раз, когда кто-либо видел это.
и оригинальная Lineage 2 - это официальный сервер типа diff. они выпускают новую версию каждые пару лет
В Lineage 2 есть около 10 различных хроник, и та, которую я пытаюсь разместить, называется hi5 freya
здесь я беру свои файлы L2J Site
и их битбакет битбакет
я использую ветку разработки

Я не хочу начинать спор о политике NCSoft по выпуску старых версий — даже Blizzard начали продавать оригинальные серверы (но я думаю, что без жестких дисков — так что не серверное программное обеспечение, а само железо) — я просто дал внутреннюю информацию. к этой сцене.

После загрузки движка и файлов базы данных я без проблем смог запустить «сервер входа» и «игровой сервер».

О вашем утверждении, что "Никто в сообществе l2j даже не видел эту ошибку": извините, что отвечаю резко, но "сцена разработки" никто не сталкивался с jvm-hard-crash с этой очень распространенной проблемой - извините , но я не могу поверить в это утверждение вообще. «EXCEPTION_ACCESS_VIOLATION (0xc0000005)» очень распространен, потому что jvm частично реализован на C, который известен своей «арифметикой указателей», которая является основной причиной любых проблем, недостатков безопасности и почти всего, что может пойти не так в современных вычисления. Таким образом, любой «обычный пользователь» хотя бы несколько раз сталкивался с проблемами, вызванными этим, не говоря уже о «разработчиках». В немецком за такое высказывание есть оскорбление: "Flaschen" - не в терминах "бутылка", а в терминах "идиоты"/"чушь".

Итак, поскольку движок и данные работают без сбоев — и, по крайней мере, если можно верить утверждению «никто не сталкивался с этой проблемой» — и что вы только что переустановили свою ОС — следующая «возможная» причина этой проблемы: аппаратная ошибка - может быть, это просто неисправность модуля оперативной памяти - может быть, проблема с процессором и / или материнской платой - но, похоже, проблема связана с вашей настройкой. Поскольку чистая установка ОС исправляет почти все - это, скорее всего, аппаратная ошибка. Просто попробуйте запустить его на другой машине, должно сработать.

Есть ли способ проверить, что не так. или мне просто нужно заменить часть за частью на моем компьютере и проверить ошибку?

наиболее распространенный инструмент, используемый для таких вещей, — memtest86
почему? большинство проблем, вызванных неисправной оперативной памятью сегодня, по крайней мере те, которые все еще позволяют вам использовать вашу систему в обычном режиме, как и ожидалось - вызывают проблемы с процессором, материнской платой, хранилищем или блоком питания, часто приводящие к сбою загрузки системы
RAM используется в конкретный способ реализации - поэтому для одной системы может случиться так, что один модуль должен быть полностью израсходован, прежде чем второй будет даже рассмотрен для использования - в другой системе это может быть совершенно случайным образом

memtest86 тестирует всю установленную системную память последовательным и повторяемым образом, чтобы его можно было использовать для определения наличия каких-либо проблем, связанных с памятью. не гарантируется, что все в порядке, поэтому, если вы запускаете memtest на никогда ранее не тестируемой системе, повторный полный запуск может быть хорошей идеей

когда memtest обнаруживает ошибки, это может означать разные вещи

1) неисправный модуль оперативной памяти - наиболее распространенный случай, который может быть решен путем замены
2) неисправная материнская плата - сюда входит весь путь от каждого контакта разъема процессора до дорожек на плате и контактов в гнездо оперативной памяти -> замена платы в качестве «ремонта» в большинстве случаев неосуществима
3) неисправный процессор - поскольку он содержит контроллер памяти, возможно возникновение проблем из-за крошечных микроразрывов внутри кремния

возможна, но встречается нечасто 4) проблема с блоком питания: блок питания не справляется с потребностями системы

полный набор тестов обычно состоит из замены по частям известными хорошими и, как уже упоминалось, для смягчения проблем с программным обеспечением с использованием другой операционной системы и клиентского программного обеспечения (что может быть вызвано использованием java)
если вы не у вас нет запасных частей попробуйте, чего вы можете достичь, изменив то, что вы можете - например, просто попробуйте linux - как вы упомянули, вы отформатировали систему и не используете ее ни для чего другого, я думаю, вы могли бы хотя бы попробовать

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

об упомянутом водителе: также может быть проблемой — плохие водители читаются для таких забавных вещей, как банкомат, который выплевывает деньги, не взимая с кого-либо счет за это, или наоборот – с вас снимают деньги, но вы не получаете бумагу – попробуйте объяснить это своему банку


Приоритет: P4

Описание

Текущий поток (0x00007fca4400b000): JavaThread "main" [_thread_in_native, stack(0x00007fca4cf02000,0x00007fca4d003000)]

siginfo: si_signo: 7 (SIGBUS), si_code: 2 (BUS_ADRERR), si_addr: 0x00007fca2c0157bc

<Р> Регистры:
RAX = 0x00007fca45967ac0, RBX = 0x00007fca45958890, RCX = 0x00007fca44000020, гексоген = 0x00007fca45967ac0
РСП = 0x00007fca4cfff960, РБП = 0x00007fca4cfff9d0, РСИ = 0x0000000000000000, RDI = 0x0000000000000003
R 8 = 0x000000000e7c1127 , R9 = 0x0000000000000050, R10 = 0x00007fca35144398, R 11 = 0x000000078c7bc428
R 12 = 0x000000000000a79e, R13 = 0x000000000e7c1127, R14 = 0x00007fca45967ac0, R15 = 0x00007fca2c01579e
RIP = 0x00007fca4a0a1d10, EFLAGS = 0x0000000000010202, CSGSFS = 0x002b000000000033, ERR = 0x0000000000000004
TRAPNO=0x000000000000000e

<Р> вершине стека: (SP = 0x00007fca4cfff960)
0x00007fca4cfff960: 0000000000000000 00007fca4d000180
0x00007fca4cfff970: 00007fca2c13b9d8 00007fca4400b000
0x00007fca4cfff980: 00007fca2c136a88 00007fca4cfff9c0
0x00007fca4cfff990: 00007fca4400b1d8 000000004bd08dc1
0x00007fca4cfff9a0: 000000000000001c 00007fca45664140
0x00007fca4cfff9b0: 000000000000001c 000000000e7c1127
0x00007fca4cfff9c0: 00007fca45958890 00007fca4595eef0
0x00007fca4cfff9d0: 00007fca4cfffa20 00007fca4a0a29fe
0x00007fca4cfff9e0: 010000000000001c 00007fca4cfffa40
0x00007fca4cfff9f0: 00007fca2c136a88 000000000000001c
0x00007fca4cfffa00: 00007fca4400b1f8 00007fca4cfffe98
0x00007fca4cfffa10: 00007fca4cfffa40 00007fca45958890
0x00007fca4cfffa20: 00007fca4cfffe80 00007fca4a093a75
0x00007fca4cfffa30: 0000000000000000 00007fca00000001
0x00007fca4cfffa40: 464e492d544f4f42 73657373616c632f
0x00007fca4cfffa50: 6f74732f6e69622f 00007f0068732e70
0x00007fca4cfffa60: 00007fca4d0004c0 00007fca4d000380
0x00007fca4cfffa70: 00007fca4400b000 0000000000000000
0x00007fca4cfffa80: 00007fca4d000190 00007fca4bf056e2
0x00007fca4cfffa90: 00007fca4d000190 00007fca4bf05550
0x00007fca4cfffaa0: 00007fca4404e0e0 0000000000000004
0x00007fca4cfffab0: 00007fca4d000368 00007fca4d00036c <бр /> 0x00007fca4cfffac0: 00007fca4cfffb40 00007fca4cfffb30
0x00007fca4cfffad0: 00007fc9f44d13d0 00007fca4cfffb50
0x00007fca4cfffae0: ffffffff00000000 00007fca459584b0
0x00007fca4cfffaf0: 00007fca459584b0 0000000700000000
0x00007fca4cfffb00: 00007fca4400b000 0000000000000000
0x00007fca4cfffb10: 0000000000000001 00007fca48398e20
0x00007fca4cfffb20: 00007f0000000073 00007fca4ba75ecf
0x00007fca4cfffb30: 000000078c7bbd90 000000078c7bbe08
0x00007fca4cfffb40: 000000078c7bbda8 00007fca4ba7b955
0x00007fca4cfffb50: 00007fca4d000248 00007fca35ae7974

Инструкции: (PC = 0x00007FCA4A0A1D10)
0x00007fca4a0a1cf0: 00 00 00 48 C7 40 28 00 00 00 00 00 4D 8B 24 24 0F
0x00007FCA4A0A1D00: 84 1B 01 00 00 4C 2B 63 28 4C 8b 7b 18 4d 01 e7
0x00007fca4a0a1d10: 41 0f b7 47 1e 45 0f b7 6f 1c 45 31 e4 66 89 45
0x00007fca4a0a1d20: ca 41 0f b7 47 20 44 8 9 ea 46 р>

Зарегистрируйтесь в отображении памяти:

RAX=0x00007fca45967ac0 — неизвестное значение
RBX=0x00007fca45958890 — неизвестное значение
RCX=0x00007fca44000020 — неизвестное значение
RDX=0x00007fca45967ac0 — неизвестное значение
RSP=0x00009ffca4 указывает на стек для потока: 0x00007fca4400b000
RBP=0x00007fca4cfff9d0 указывает на стек для потока: 0x00007fca4400b000
RSI=0x00000000000000000 — неизвестное значение
RDI=0x0000000000000
RDI=0x0000000000000 — неизвестное значение >R8 =0x000000000e7c1127 — неизвестное значение
R9 =0x0000000000000050 — неизвестное значение
R10=0x00007fca35144398 находится в entry_point+88 в (nmethod*)0x00007fca351441d0
R11=0x07087bcp >

Читайте также: