Exception in native code v1.1b10

[sTyLeS]

I’ve been upgrading to the recent versions of jogl shortly after they come out. Recently I’ve tried version 1.1b10, and consistently get a native code exception. I have not received this error in any of the other versions. Anybody else seen this in the recent version?
Below is the dump:

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x36F144B
Function=[Unknown.]
Library=C:\WINDOWS\system32\ialmgicd.dll

NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for possible
reason and solutions.

Current Java thread:
at net.java.games.jogl.impl.windows.WindowsGLImpl.glGenTextures(Native Method)
at Lesson18.initCustom(Lesson18.java:172)
at Renderer.init(Renderer.java:213)
at net.java.games.jogl.impl.GLDrawableHelper.init(GLDrawableHelper.java:68)
at net.java.games.jogl.GLCanvas$InitAction.run(GLCanvas.java:234)
at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:171)
- locked <0x10091180> (a net.java.games.jogl.impl.windows.WindowsOnscreenGLContext)
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:129)
- locked <0x10091180> (a net.java.games.jogl.impl.windows.WindowsOnscreenGLContext)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:246)
- locked <0x10091180> (a net.java.games.jogl.impl.windows.WindowsOnscreenGLContext)
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.invokeGL(WindowsOnscreenGLContext.java:76)
- locked <0x105b2f40> (a java.awt.Component$AWTTreeLock)
at net.java.games.jogl.GLCanvas$2.run(GLCanvas.java:122)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

Dynamic libraries:
0x00400000 - 0x0040B000 C:\j2sdk1.4.2_05\jre\bin\javaw.exe
0x7C900000 - 0x7C9B0000 C:\WINDOWS\system32\ntdll.dll
0x7C800000 - 0x7C8F4000 C:\WINDOWS\system32\kernel32.dll
0x77DD0000 - 0x77E6B000 C:\WINDOWS\system32\ADVAPI32.dll
0x77E70000 - 0x77F01000 C:\WINDOWS\system32\RPCRT4.dll
0x77D40000 - 0x77DD0000 C:\WINDOWS\system32\USER32.dll
0x77F10000 - 0x77F56000 C:\WINDOWS\system32\GDI32.dll
0x77C10000 - 0x77C68000 C:\WINDOWS\system32\MSVCRT.dll
0x08000000 - 0x08139000 C:\j2sdk1.4.2_05\jre\bin\client\jvm.dll
0x76B40000 - 0x76B6D000 C:\WINDOWS\system32\WINMM.dll
0x10000000 - 0x10007000 C:\j2sdk1.4.2_05\jre\bin\hpi.dll
0x00830000 - 0x0083E000 C:\j2sdk1.4.2_05\jre\bin\verify.dll
0x00840000 - 0x00859000 C:\j2sdk1.4.2_05\jre\bin\java.dll
0x00860000 - 0x0086D000 C:\j2sdk1.4.2_05\jre\bin\zip.dll
0x02E50000 - 0x02F62000 C:\j2sdk1.4.2_05\jre\bin\awt.dll
0x73000000 - 0x73026000 C:\WINDOWS\system32\WINSPOOL.DRV
0x76390000 - 0x763AD000 C:\WINDOWS\system32\IMM32.dll
0x774E0000 - 0x7761D000 C:\WINDOWS\system32\ole32.dll
0x5AD70000 - 0x5ADA8000 C:\WINDOWS\system32\uxtheme.dll
0x02FE0000 - 0x03031000 C:\j2sdk1.4.2_05\jre\bin\fontmanager.dll
0x73760000 - 0x737A9000 C:\WINDOWS\system32\ddraw.dll
0x73BC0000 - 0x73BC6000 C:\WINDOWS\system32\DCIMAN32.dll
0x73940000 - 0x73A10000 C:\WINDOWS\system32\D3DIM700.DLL
0x74720000 - 0x7476B000 C:\WINDOWS\system32\MSCTF.dll
0x77120000 - 0x771AC000 C:\WINDOWS\system32\OLEAUT32.DLL
0x031A0000 - 0x031A5000 C:\j2sdk1.4.2_05\jre\bin\jawt.dll
0x03230000 - 0x03290000 C:\WINDOWS\system32\jogl.dll
0x5ED00000 - 0x5EDCC000 C:\WINDOWS\system32\OPENGL32.dll
0x68B20000 - 0x68B40000 C:\WINDOWS\system32\GLU32.dll
0x036E0000 - 0x03913000 C:\WINDOWS\system32\ialmgicd.dll
0x039C0000 - 0x03A40000 C:\WINDOWS\system32\ialmgdev.dll
0x76C90000 - 0x76CB8000 C:\WINDOWS\system32\imagehlp.dll
0x59A60000 - 0x59B01000 C:\WINDOWS\system32\DBGHELP.dll
0x77C00000 - 0x77C08000 C:\WINDOWS\system32\VERSION.dll
0x76BF0000 - 0x76BFB000 C:\WINDOWS\system32\PSAPI.DLL

Heap at VM Abort:
Heap
def new generation total 576K, used 130K [0x10010000, 0x100b0000, 0x104f0000)
eden space 512K, 13% used [0x10010000, 0x10020a58, 0x10090000)
from space 64K, 100% used [0x10090000, 0x100a0000, 0x100a0000)
to space 64K, 0% used [0x100a0000, 0x100a0000, 0x100b0000)
tenured generation total 1408K, used 1077K [0x104f0000, 0x10650000, 0x14010000)
the space 1408K, 76% used [0x104f0000, 0x105fd6d8, 0x105fd800, 0x10650000)
compacting perm gen total 6656K, used 6514K [0x14010000, 0x14690000, 0x18010000)
the space 6656K, 97% used [0x14010000, 0x1466cbc8, 0x1466cc00, 0x14690000)

Local Time = Tue Mar 29 15:13:28 2005
Elapsed Time = 2

The exception above was detected in native code outside the VM

Java VM: Java HotSpot™ Client VM (1.4.2_05-b04 mixed mode)

[kbr]

Have you checked to make sure you upgraded both your jogl.dll and jogl.jar? Nehe’s Lesson 18 works fine for me; are you running the most recent set of Intel graphics drivers?

[sTyLeS]

I did download both the native .dll’s and the jogl.jar from the same posted binaries page…so they should be fine. I did get the latest Intel drivers as well when I noticed the problem. No go.
It’s not just NeHe’s Lesson 18, it’s any of the lessons that call the gl.glGenTextures() method. That’s where it’s failing.
But like I mentioned. Every previous version runs them all just fine.
If you look near the top of the dump where it says:
Library=C:\WINDOWS\system32\ialmgicd.dll
Someone correct me if I’m wrong, but I believe the ialmgicd.dll is Intel’s OpenGL video driver. Is it possible there’s something buggy there, or in JOGL?
Thanks!

[kbr]

It’s possible that there is a bug in JOGL, possibly relating to multithreading behavior. The most significant change in 1.1 b10 compared to 1.1 b09 was the change to use the “single-threaded workaround” in the JOGL code by default. This causes the GLEventListeners’ callbacks to all be executed on the AWT event queue thread and works around problems seen on most platforms related to bugs either in vendors’ OpenGL drivers or in the J2SE implementation. Does specifying -Djogl.1thread=false on the command line change the behavior of these applications on your machine?

[sTyLeS]

[quote] Does specifying -Djogl.1thread=false on the command line change the behavior of these applications on your machine?
[/quote]
Yes! That did the trick. But what does that mean?

[kbr]

It probably means that JOGL’s attempt to do all OpenGL work on the AWT event queue thread isn’t completely correct and that your drivers are catching this. Most other drivers behave better with our attempts to force all work onto the AWT event queue thread. Please file a bug using the Issue Tracker on the JOGL web page (you’ll need to be an Observer of the project; request Observer status if you haven’t already) and include as much detail as you can including a test case, graphics card chipset, driver level, CPU type and number of CPUs.