5

I am using JME in my application and sometimes it crashes with the following message:

#
# 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.
#

The log file can be found by this link: http://sergpank.heliohost.org/log.html

The strangest thing is that in my case I get crashes only ob builded code, but when I am launcing it from the Eclipse, everything works fine on my machine. On machines with AMD video adapters nothing crashes. On other machines with Intel videocard sometimes crashes appear and on the debug stage.

I am starting to suppose that this happens because of incorrect ant setup (in startup.ini the following path is set up: -Djava.library.path=lib/dlls so dlls is seen for the project). But still can't get why it works almost perfectly on AMD and crashes on Intel.

Maybe it is something related to the ant, and I have to add dlls to the manfest... looking through the documentation and can't find the way how it can be done.

Solution:

On 64 bit system is necessary to use the corresponding JVM(64-bit) and then nothing crashes =))

sergpank
  • 988
  • 10
  • 18
  • Given that you do not experience the crashes on other hardwre, the problem is almost certainly driver-related, which means the gist of the answer boils down to the unhelpful, but accurate "yep, that's the Intel drivers for you". Be sure your drivers are up to date, and try again. If you post the stack trace portion of the hs_err_pid168.log file that was generated (open it up, it's just a text file), that might at least help in determining which calls led up to the crash. – Chuck Adams Jan 10 '12 at 01:23
  • The log gile looks like that: http://sergpank.heliohost.org/log.html Hope it says about the issue =) – sergpank Jan 10 '12 at 09:06

2 Answers2

2

Crash happens because 32-bit JVM was used on 64-bit OS. It seems that in this case 32-bit dlls was loaded and that's why crash happened.

Issue is reproducible only on Intel video cards, I think it can be considered as a serious bug. If Intel would like to fix it or propose a working solution/workaround this could be great! =)

sergpank
  • 988
  • 10
  • 18
1

Avoid doing the heavy work of the OpenGL stuff in the Swing Event Dispatch Thread (note the thread which crashes the JVM: =>0x3a88e000 JavaThread "AWT-EventQueue-0" [_thread_in_native, id=5228, stack(0x3b170000,0x3b1c0000)). I believe OpenGL stuff should be done in the thread offered by JMonkeyEngine using the event dispatch mechanism it has. If you're using somebody else's API for Swing rendering, you might need to change it or do it a different way.

Edit: it looks like AWTGLCanvas does this, changing the context to the current thread. It looks like the Intel drivers may have trouble with context switches if normal fullscreen 3D stuff works. Strictly speaking, the GL thread context stuff shouldn't be necessary as you can always dispatch work to be executed to a singular OpenGL thread which should be fine as long as you only have a single OpenGL rendering viewport. The LWJGL Canvas implementation assumes you will want multiple viewports when this isn't necessarily the case. You can recode this to only support one viewport if that is fine, and you shouldn't get crashes as the code is simpler.

Chris Dennett
  • 22,412
  • 8
  • 58
  • 84
  • Thanks, I've noticed that on 64 bit system it works, but only with 64 bit jre, even if code was compiled using 32 bit jdk.. – sergpank Jan 10 '12 at 13:12
  • Have also noticed that Intel drivers have issues with gl_quads: http://communities.intel.com/thread/24803 – sergpank Jan 10 '12 at 13:18
  • @sergpank it doesn't matter if your code is compiled with a 32-bit or 64-bit JDK; Java bytecode is independent from the "bitness" of the platform. There is no 32-bit or 64-bit Java bytecode. – Jesper Jan 10 '12 at 14:16
  • @Jesper than maybe the issue is that I am on Windows 7 64 bit.. Java part works perfectly, but when I am starting to deal with native libraries I am getting crashes if the project is being runned on 32-bit JRE.. – sergpank Jan 10 '12 at 14:43
  • 1
    @sergpank (As far as I know) if you're using 32-bit native libraries, then you'd need a 32-bit JRE; if you're using 64-bit native libs, you'd need a 64-bit JRE. In principle 32-bit libs should also work on a 64-bit system, but there could be specific issues with the libs that you're using. – Jesper Jan 12 '12 at 12:15
  • @Jesper, that's what we have also decided. If win ix 64bit then jmonkey doesn't crash only if JRE is 64 bit, if JRE is 32bit the it uses the 32bit dlls and crashes. The most strange thing is that why this issue appears only on Intel adapters... Thanks for you assistance, i suppouse the issue can be considered as resolved. – sergpank Jan 13 '12 at 09:48
  • 1
    @sergpank if it really only happens with Intel graphics and not with other brands, it could very well be a bug in the Intel graphics driver. – Jesper Jan 13 '12 at 13:57