If I close my JOGL app like this, my JVM crashes. Do I need to do some JOGL cleanup before exiting?
instance.frame.addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) { System.exit(0); }
} );
Try taking a look at the demos that
come with JOGL, specifically those that
use the Animator class. The Animator
shows how to properly stop JOGL rendering
and then exiting the JVM.
I found this in the Gears demo, but it still crashes when I close the window. :-/ Not a big deal for me on windows, just leaves a log behind after each crash. But, I have a friend who is running it on Linux, and it kills his XWindows. :o
addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
// Run this on another thread than the AWT event queue to
// make sure the call to Animator.stop() completes before exiting
new Thread(new Runnable() {
public void run() {
animator.stop();
Client.log.info( "animator stopped");
System.exit(0);
}
}).start();
}
});
(ClientFrame$1$1:00:41:39:0687) animator stopped
An unexpected error has been detected by HotSpot Virtual Machine:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x696b2468, pid=2396, tid=3488
Java VM: Java HotSpot™ Client VM (1.5.0_01-b08 mixed mode)
Problematic frame:
C [nvoglnt.dll+0x1b2468]
An error report file with more information is saved as hs_err_pid2396.log
If you would like to submit a bug report, please visit:
http://java.sun.com/webapps/bugreport/crash.jsp
What nVidia card are you using and what’s
the version of the driver installed?
Have you tried installing the latest drivers
from http://www.nvidia.com/content/drivers/drivers.asp?
Do the JOGL demos crash upon exit? If they exit cleanly then you need to make sure you aren’t trying to do any OpenGL rendering during teardown. As Rex already pointed out the Gears demo and others have code which ensures this, though you may have to adapt it somewhat for your application. Are you using the latest version of JOGL (1.1 b10)?
Video Card: GeForce4 Ti 4200
I updated to the drivers from the link you gave me, tx. Still crashes.
The Gears demo does not crash when exiting.
How can I make sure I’m not trying to render during teardown? I stop the animator before calling System.exit. I even tried sleeping for a sec after stopping the animator, and made sure my display() method didn’t continue to get called.
Not sure about version. I grabbed latest version 2 or 3 weeks ago, so whatever was there then. Is there an easy way to tell the version of JOGL running?
Here’s one of my crash logs:
An unexpected error has been detected by HotSpot Virtual Machine:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x696b2468, pid=3996, tid=2364
Java VM: Java HotSpot™ Client VM (1.5.0_01-b08 mixed mode)
Problematic frame:
C [nvoglnt.dll+0x1b2468]
--------------- T H R E A D ---------------
Current thread (0x00a83490): VMThread [id=2364]
siginfo: ExceptionCode=0xc0000005, reading address 0x00000041
Registers:
EAX=0x69877614, EBX=0x0c5400c0, ECX=0x0be915c0, EDX=0x69889860
ESP=0x009af9b0, EBP=0x00000000, ESI=0x0be91600, EDI=0x00000041
EIP=0x696b2468, EFLAGS=0x00010293
Top of Stack: (sp=0x009af9b0)
0x009af9b0: 00000000 0000000d 0be91600 0c5400c0
0x009af9c0: 696dfb83 0c5400c0 00000041 00000004
0x009af9d0: 00000001 0be91580 0c5400c0 696dfb27
0x009af9e0: 0c5400c0 0be8a980 0be91600 00000001
0x009af9f0: 00000004 0c5400c0 0be8a980 00000003
0x009afa00: 696dfc57 0c5400c0 0be8a980 0be91580
0x009afa10: 00000000 0c551264 0c5400c0 0000000a
0x009afa20: 696b18b6 0c5400c0 0be8a980 00000000
Instructions: (pc=0x696b2468)
0x696b2458: 00 5e c3 cc cc cc cc cc 53 56 57 55 8b 7c 24 18
0x696b2468: 8b 1f 4b 89 1f 75 48 8b 74 24 14 8b 86 94 c9 09
Stack: [0x00970000,0x009b0000), sp=0x009af9b0, free space=254k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [nvoglnt.dll+0x1b2468]
[error occurred during error reporting, step 120, id 0xc0000005]
VM_Operation (0x0c91fa84): exit, mode: safepoint, requested by thread 0x0b3da098
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x0b3da098 JavaThread “Thread-5” [_thread_blocked, id=1592]
0x00036ad0 JavaThread “DestroyJavaVM” [_thread_blocked, id=488]
0x0ad51b58 JavaThread “AWT-EventQueue-0” [_thread_blocked, id=1424]
0x0ad15bf8 JavaThread “AWT-Shutdown” [_thread_blocked, id=4012]
0x0ad32da8 JavaThread “Java2D Disposer” daemon [_thread_blocked, id=2804]
0x00acf980 JavaThread “Monitor Ctrl-Break” daemon [_thread_in_native, id=256]
0x00a91e50 JavaThread “Low Memory Detector” daemon [_thread_blocked, id=3880]
0x00a90998 JavaThread “CompilerThread0” daemon [_thread_blocked, id=2316]
0x00a8fd20 JavaThread “Signal Dispatcher” daemon [_thread_blocked, id=1768]
0x00a872f0 JavaThread “Finalizer” daemon [_thread_blocked, id=3272]
0x00a85e60 JavaThread “Reference Handler” daemon [_thread_blocked, id=2304]
Other Threads:
=>0x00a83490 VMThread [id=2364]
VM state:at safepoint (shutting down)
VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x00036148/0x0000171c] Threads_lock - owner thread: 0x00a83490
Heap
def new generation total 576K, used 192K [0x02ad0000, 0x02b70000, 0x02fb0000)
eden space 512K, 37% used [0x02ad0000, 0x02affdf8, 0x02b50000)
from space 64K, 1% used [0x02b50000, 0x02b504d8, 0x02b60000)
to space 64K, 0% used [0x02b60000, 0x02b60000, 0x02b70000)
tenured generation total 5792K, used 5565K [0x02fb0000, 0x03558000, 0x06ad0000)
the space 5792K, 96% used [0x02fb0000, 0x0351f498, 0x0351f600, 0x03558000)
compacting perm gen total 9984K, used 9860K [0x06ad0000, 0x07490000, 0x0aad0000)
the space 9984K, 98% used [0x06ad0000, 0x07471110, 0x07471200, 0x07490000)
No shared spaces configured.
Dynamic libraries:
0x00400000 - 0x0040c000 C:\jdk1.5.0_01\bin\java.exe
0x7c900000 - 0x7c9b0000 C:\WINNT\system32\ntdll.dll
0x7c800000 - 0x7c8f4000 C:\WINNT\system32\kernel32.dll
0x77dd0000 - 0x77e6b000 C:\WINNT\system32\ADVAPI32.dll
0x77e70000 - 0x77f01000 C:\WINNT\system32\RPCRT4.dll
0x77c10000 - 0x77c68000 C:\WINNT\system32\MSVCRT.dll
0x6d6b0000 - 0x6d835000 C:\jdk1.5.0_01\jre\bin\client\jvm.dll
0x77d40000 - 0x77dd0000 C:\WINNT\system32\USER32.dll
0x77f10000 - 0x77f56000 C:\WINNT\system32\GDI32.dll
0x76b40000 - 0x76b6d000 C:\WINNT\system32\WINMM.dll
0x5cd70000 - 0x5cd77000 C:\WINNT\system32\serwvdrv.dll
0x5b0a0000 - 0x5b0a7000 C:\WINNT\system32\umdmxfrm.dll
0x6d2f0000 - 0x6d2f8000 C:\jdk1.5.0_01\jre\bin\hpi.dll
0x76bf0000 - 0x76bfb000 C:\WINNT\system32\PSAPI.DLL
0x6d680000 - 0x6d68c000 C:\jdk1.5.0_01\jre\bin\verify.dll
0x6d370000 - 0x6d38d000 C:\jdk1.5.0_01\jre\bin\java.dll
0x6d6a0000 - 0x6d6af000 C:\jdk1.5.0_01\jre\bin\zip.dll
0x10000000 - 0x10007000 C:\IntelliJ-IDEA-4.5\bin\breakgen.dll
0x6d530000 - 0x6d543000 C:\jdk1.5.0_01\jre\bin\net.dll
0x71ab0000 - 0x71ac7000 C:\WINNT\system32\WS2_32.dll
0x71aa0000 - 0x71aa8000 C:\WINNT\system32\WS2HELP.dll
0x71a50000 - 0x71a8f000 C:\WINNT\system32\mswsock.dll
0x662b0000 - 0x66308000 C:\WINNT\system32\hnetcfg.dll
0x71a90000 - 0x71a98000 C:\WINNT\System32\wshtcpip.dll
0x6d550000 - 0x6d559000 C:\jdk1.5.0_01\jre\bin\nio.dll
0x6d070000 - 0x6d1d6000 C:\jdk1.5.0_01\jre\bin\awt.dll
0x73000000 - 0x73026000 C:\WINNT\system32\WINSPOOL.DRV
0x76390000 - 0x763ad000 C:\WINNT\system32\IMM32.dll
0x774e0000 - 0x7761d000 C:\WINNT\system32\ole32.dll
0x5ad70000 - 0x5ada8000 C:\WINNT\system32\uxtheme.dll
0x73760000 - 0x737a9000 C:\WINNT\system32\ddraw.dll
0x73bc0000 - 0x73bc6000 C:\WINNT\system32\DCIMAN32.dll
0x73940000 - 0x73a10000 C:\WINNT\system32\D3DIM700.DLL
0x6d2b0000 - 0x6d2ed000 C:\jdk1.5.0_01\jre\bin\fontmanager.dll
0x7c9c0000 - 0x7d1d4000 C:\WINNT\system32\shell32.dll
0x77f60000 - 0x77fd6000 C:\WINNT\system32\SHLWAPI.dll
0x773d0000 - 0x774d2000 C:\WINNT\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll
0x5d090000 - 0x5d127000 C:\WINNT\system32\comctl32.dll
0x60300000 - 0x60307000 C:\Program Files\Yahoo!\Messenger\idle.dll
0x7c340000 - 0x7c396000 C:\Program Files\Yahoo!\Messenger\MSVCR71.dll
0x0b1c0000 - 0x0b1cf000 C:\Program Files\allSnap\snap_libW.dll
0x6d3d0000 - 0x6d3d6000 C:\jdk1.5.0_01\jre\bin\jawt.dll
0x0b600000 - 0x0b660000 C:\jdk1.5.0_01\jre\bin\jogl.dll
0x5ed00000 - 0x5edcc000 C:\WINNT\system32\OPENGL32.dll
0x68b20000 - 0x68b40000 C:\WINNT\system32\GLU32.dll
0x69500000 - 0x698c1000 C:\WINNT\system32\nvoglnt.dll
0x6d200000 - 0x6d22f000 C:\jdk1.5.0_01\jre\bin\cmm.dll
0x6d430000 - 0x6d44f000 C:\jdk1.5.0_01\jre\bin\jpeg.dll
VM Arguments:
jvm_args: -Didea.launcher.port=7536 -Didea.launcher.library=C:\IntelliJ-IDEA-4.5\bin\breakgen.dll -Dfile.encoding=windows-1252
java_command: com.intellij.rt.execution.application.AppMain org.hcmmog.client.Client client.properties
Environment Variables:
JAVA_HOME=C:\jdk1.5.0_01
CLASSPATH=C:\IntelliJ-IDEA-4.5\lib\idea.jar;C:\IntelliJ-IDEA-4.5\lib\jdom.jar;C:\IntelliJ-IDEA-4.5\lib\log4j.jar;C:\IntelliJ-IDEA-4.5\lib\openapi.jar;C:\IntelliJ-IDEA-4.5\bin\lax.jar;
PATH=C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;c:\Program Files\Common Files\Adaptec Shared\System;C:\Program Files\Common Files\GTK\2.0\bin;C:\jwsdp-1.5\jwsdp-shared\bin;C:\jdk1.5.0_01\jre\bin;C:\dev\tools\apache-ant-1.6.2\bin;C:\cvs-1.11.5;C:\irrlicht-0.7\bin\DevCpp
USERNAME=Owner
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 15 Model 2 Stepping 9, GenuineIntel
--------------- S Y S T E M ---------------
OS: Windows XP Build 2600 Service Pack 2
CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht
Memory: 4k page, physical 1047276k(506112k free), swap 2522784k(2086444k free)
vm_info: Java HotSpot™ Client VM (1.5.0_01-b08) for windows-x86, built on Dec 6 2004 19:51:00 by “java_re” with MS VC++ 6.0
You can get JOGL to print its version
to the console by adding this line to
the very start of your app:
System.setProperty("jogl.verbose", "true");
The current version of JOGL is v1.1b10.
Tx, added that to program. I’m running latest version:
JOGL version 1.1.0-b10
I don’t know how that crash is happening; no Java code should be running on the VM thread (as an invariant in HotSpot) so it isn’t clear to me how the PC appears to be inside nvoglnt.dll.
Could you look carefully at the shutdown code used in the Gears demo? To avoid deadlocks on certain platforms it actually starts up a thread to perform the animator.stop() and System.exit() calls. Are you sure your app is doing something similar?
Yes, I’m sure. Here’s the code:
addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
// Run this on another thread than the AWT event queue to
// make sure the call to Animator.stop() completes before exiting
new Thread(new Runnable() {
public void run() {
animator.stop();
Client.log.info( "animator stopped");
// Common.delay( 1000 );
// Client.log.info( “slept 1 sec”);
System.exit(0); // BOOM!
}
}).start();
}
});Can you boil down your program to a small test case? Could you file a bug with the JOGL Issue Tracker and attach it?
Ken and Rex,
Thanks for your help. As I was trying to come up with minimal app that reproduces the crash, I found the source of it. I had a method that would turn off textures and draw a few lines. I was doing it like this:
gl.glBindTexture(GL.GL_TEXTURE_2D, -1 );
I guess this is bad. When I changed the method to this, it stopped crashing on exit:
myMethod()
{
gl.glDisable(GL.GL_TEXTURE_2D);
<draw some stuff here>
gl.glEnable(GL.GL_TEXTURE_2D);
}
Darrel
Glad you tracked down your problem. However did you try using the DebugGL pipeline? If not, would you try putting back in the buggy code and installing the DebugGL at the top of your application (the Gears source code gives an example of how to do this)? Hopefully it should catch the error as it happens. The DebugGL is a useful tool designed to be used during development; please file bugs if it causes any errors to be introduced into the application.