Сбой JMonkeyEngine на видеоадаптере Intel - PullRequest
Новая
       43

Сбой JMonkeyEngine на видеоадаптере Intel

5 голосов
/ 10 января 2012

Я использую JME в своем приложении, и иногда происходит сбой со следующим сообщением: 

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x3d601ad7, pid=168, tid=4012
#
# JRE version: 6.0_29-b11
# Java VM: Java HotSpot(TM) Client VM (20.4-b02 mixed mode, sharing windows-x86)
# Problematic frame:
# C  [ig4dev32.dll+0x21ad7]
#
# An error report file with more information is saved as:
# C:\...\hs_err_pid168.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

Файл журнала можно найти по этой ссылке: http://sergpank.heliohost.org/log.html

Самое странноев том, что в моем случае происходит сбой только встроенного кода, но когда я запускаю его из Eclipse, на моей машине все работает нормально.На машинах с видеоадаптерами AMD ничего не вылетает.На других машинах с видеокартой Intel иногда возникают сбои и на этапе отладки.

Я начинаю предполагать, что это происходит из-за неправильной настройки муравья (в файле startup.ini указан следующий путь: -Djava.library.path = lib / dlls, поэтому dll виден для проекта).Но до сих пор не могу понять, почему он работает почти идеально на AMD и вылетает на Intel.

Может быть, это что-то, связанное с муравьем, и я должен добавить dll к manfest ... просматривая документацию ине могу найти способ, как это можно сделать.

Решение:

В 64-битной системе необходимо использовать соответствующую JVM (64-битную), и тогда ничего не вылетает =))

Ответы [ 2 ]

2 голосов
/ 15 января 2012

Сбой произошел из-за того, что 32-разрядная JVM использовалась в 64-разрядной ОС.Кажется, что в этом случае 32-битные dll были загружены, и именно поэтому произошел сбой.

Проблема воспроизводима только на видеокартах Intel, я думаю, что это можно рассматривать как серьезную ошибку.Если Intel захочет это исправить или предложить рабочее решение / обходной путь, это будет здорово!=)

1 голос
/ 10 января 2012

Старайтесь не выполнять тяжелую работу с OpenGL в потоке рассылки событий Swing (обратите внимание на поток, в котором происходит сбой JVM: =>0x3a88e000 JavaThread "AWT-EventQueue-0" [_thread_in_native, id=5228, stack(0x3b170000,0x3b1c0000)). Я считаю, что работа с OpenGL должна выполняться в потоке, предлагаемом JMonkeyEngine, с использованием имеющегося механизма обработки событий. Если вы используете чей-то API для рендеринга Swing, вам, возможно, придется изменить его или сделать это другим способом.

Редактировать: похоже, что AWTGLCanvas делает это, изменяя контекст на текущий поток. Похоже, что драйверы Intel могут иметь проблемы с переключением контекста, если работает нормальный полноэкранный режим 3D. Строго говоря, контекстная среда потока GL не обязательна, так как вы всегда можете отправить выполняемую работу в отдельный поток OpenGL, что должно быть хорошо, если у вас только один видовой экран рендеринга OpenGL. Реализация LWJGL Canvas предполагает, что вам понадобятся несколько окон просмотра, когда это не обязательно так. Вы можете перекодировать это, чтобы поддерживать только один видовой экран, если это хорошо, и вы не должны получать сбои, поскольку код проще.

...