This may be completely unrelated to your problem, but my XP box reboots when I call animator.stop!
Also using NVidia. I suppose my point is that I think NVidia’s drivers are not playing nice with jogl at the moment. On any of the machines in my house with ATI cards, all is well.
…so for the moment, I just do all my dev on my mac or my bsd box (both have ati cards), and if I have to run it on my PC, I just don’t call animator.stop
I think there is a bug in JOGL’s context destruction on X11 platforms. There is an issue filed (#124) which we are currently investigating which looks like there is inadequate locking around the glXDestroyContext call. However, people have reported crashes upon exit on Linux with NVidia cards before that appear to be driver-related. Make sure you are running a recent set of drivers.
The reboot on exit on Windows XP boxes has been reported before and is clearly a driver bug but it isn’t clear to me whether JOGL is doing anything illegal according to the OpenGL and WGL specifications. Someone else on the forums reported that the problem went away after upgrading to an (unofficial) later driver build.
[quote]Have you tried calling setRenderingThread(null) before frame.dispose()?
[/quote]
I use the following workaround in Jake2.
if (frame != null) {
// this is very important to change the GL context
if (canvas != null) {
canvas.setVisible(false);
frame.remove(canvas);
canvas = null;
}
frame.dispose();
}
The frame.dispose() should handle this correctly but it doesn’t.
I had the same problem (XP booting) and it went away by updating drivers. I tried lots of things but none worked. I had to assume it to be a driver bug (which nVidia has alot).
I can report a similar problem the other way round. I am developing a jogl application on my dell inspiron 8200 notebook which has a nvidia graphics card. Everything runs fine here with jogl 1.0 and 1.1b7.
But the app crashes Windows XP on exit. It doesn’t depend on animator.stop(). It just kills the machine if I press ctrl-c in the cmd shell. The only way to kill the application without rebooting is to kill it via the task manager.
On the Windows XP machines there are Matrox parhelia triple- and quadhead cards doing the job.
Is there an open issues depending on multihead? Or is a similar problem known for matrox graphics drivers like it is for nvidias?
There is no way a user application should be able to kill the OS so obviously there is some sort of bug in the drivers. The question is what JOGL is doing to trigger that bug. Please try the forthcoming 1.1 b08 (should be out later today) and specify -DJOGL_SINGLE_THREADED_WORKAROUND=true on the command line; let us know whether that works around the problem. You should be able to get similar results out of 1.1 b07 if you specify -DATI_WORKAROUND=true, though there are bugs in 1.1 b07 that may prevent the workaround from functioning as intended.
With 1.1b8 and the -DJOGL_SINGLE_THREADED_WORKAROUND=true
I noticed only slightly differences which are not 100% reproducable. The test of hitting ctrl-c reboots the machine.
Using ESC to utilize my own exit handler I get only a virtual machine error. Everytime I exit via ESC there is an error in mtxogl.dll.
When hitting ctrl-c and getting a glimpse of the blue screen before the machine reboots there is a notification about a failure in mxparh.dll.
Is there any additional information I could provide?
I did all tests with jdk 1.5.0_01.
There is one possibility to prevent the access violation. If I turn down the hardware acceleration in display driver->advanced->problem… (I don’t know how this called in english exactly) there is no such excecption and the program exits normal. On the tab I described there is a slider where you can adjust the amount of hardware acceleration. On the left side there is no acceleration. I can put the slider one position to the right (nearly no acceleration). With this setting no exception occurs. On the next position to the right the execption occurs.
The log you wanted when the virtual machine was crashing is this one:
An unexpected error has been detected by HotSpot Virtual Machine:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x068fae38, pid=2208, tid=3020
Java VM: Java HotSpot™ Client VM (1.5.0_01-b08 mixed mode, sharing)
Stack: [0x00990000,0x009d0000), sp=0x009cfbf4, free space=254k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [MTXOGL.DLL+0x1ae38]
C [MTXOGL.DLL+0x2064]
C [MTXOGL.DLL+0x1955c]
C [ntdll.dll+0x11a7]
C [ntdll.dll+0x23f31]
C [kernel32.dll+0x1ca3e]
C [kernel32.dll+0x1cab6]
C [MSVCRT.dll+0x29d45]
C [MSVCRT.dll+0x29e78]
C [MSVCRT.dll+0x29e90]
V [jvm.dll+0x118449]
V [jvm.dll+0x117887]
V [jvm.dll+0x117a27]
V [jvm.dll+0x1177bc]
C [MSVCRT.dll+0x2a3b0]
C [kernel32.dll+0xb50b]
VM_Operation (0x0689f634): exit, mode: safepoint, requested by thread 0x0304eed0
VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x000351b0/0x0000071c] Threads_lock - owner thread: 0x00a5d6b8
Heap
def new generation total 1152K, used 316K [0x22a60000, 0x22ba0000, 0x22f40000)
eden space 1024K, 18% used [0x22a60000, 0x22a8f2b0, 0x22b60000)
from space 128K, 100% used [0x22b60000, 0x22b80000, 0x22b80000)
to space 128K, 0% used [0x22b80000, 0x22b80000, 0x22ba0000)
tenured generation total 14556K, used 9797K [0x22f40000, 0x23d77000, 0x26a60000)
the space 14556K, 67% used [0x22f40000, 0x238d1770, 0x238d1800, 0x23d77000)
compacting perm gen total 8192K, used 2738K [0x26a60000, 0x27260000, 0x2aa60000)
the space 8192K, 33% used [0x26a60000, 0x26d0c928, 0x26d0ca00, 0x27260000)
ro space 8192K, 62% used [0x2aa60000, 0x2af67d30, 0x2af67e00, 0x2b260000)
rw space 12288K, 46% used [0x2b260000, 0x2b7ec8a0, 0x2b7eca00, 0x2be60000)
[quote]Could you run with 1.5 and post the error log for the case where you hit escape and the JVM (but not the entire machine) crashes?
[/quote]
Ken, I get similar crashes of the JVM (1.5 on Windows XP) when using the Animator, although not always, and not always the same error. It seems that calling animator.stop() has no influence. On the other hand, the -DJOGL_SINGLE_THREADED_WORKAROUND=true flag cures the situation. When it crashes, I get two different types of errors:
1)
An unexpected error has been detected by HotSpot Virtual Machine:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x69621566, pid=3388, tid=3236
Java VM: Java HotSpot™ Client VM (1.5.0-b64 mixed mode)
Problematic frame:
C [nvoglnt.dll+0x121566]
An error report file with more information is saved as hs_err_pid3388.log
Exception in thread “Thread-4” net.java.games.jogl.GLException: Error swapping buffers
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.swapBuffers(WindowsOnscreenGLContext.java:159)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:285)
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.invokeGL(WindowsOnscreenGLContext.java:79)
at net.java.games.jogl.impl.GLContext.setRenderingThread(GLContext.java:421)
at net.java.games.jogl.GLCanvas.setRenderingThread(GLCanvas.java:163)
at net.java.games.jogl.Animator$1.run(Animator.java:123)
at java.lang.Thread.run(Thread.java:595)
[quote]I get similar crashes of the JVM (1.5 on Windows XP) when using the Animator, although not always, and not always the same error.
[/quote]
An “error swapping buffers” exception upon exit if you hit Ctrl-C when an Animator is running is to be expected. The Ctrl-C causes the window to be torn down from underneath the Animator while it’s running. Most of the JOGL demos stop the animator and exit the process cooperatively to make sure no OpenGL drawing is occurring while the JVM exits.
For the first crash you see, does this occur with the JOGL demos as well when you don’t enable the single-threaded workaround? If so, what version of the NVidia drivers are you using, and what card do you have?
Could you try the VertexProgRefract demo and try exiting it “cleanly”, i.e., by either closing the window or clicking it and pressing ‘Escape’ or ‘Q’? Does it crash in the same way? Could you post the complete HotSpot error log (including the backtrace of the crashing thread) if so?
I’m running the 66.93 drivers on my 5800 Ultra with no problems. I think there are bugs in the 6800 support because other 6800 users have reported similar crashes. Is there a later driver for you to try? if not, could you file a bug on NVidia’s web site?
When closing the window, the demo crashes (consistently) , but using Escape or Q there seems to be no problem! When I run my own program, the crashes occur in an “erratic” way: sometimes normal termination, sometimes an immediate crash, sometimes the window disappears, then reappears.
The 66.93 driver is the latest non-beta, for all Gforce cards.
The error log file (hs-err-pid3756.log) for the VertexProgRefract demo :
An unexpected error has been detected by HotSpot Virtual Machine:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6966499a, pid=3756, tid=3484
Java VM: Java HotSpot™ Client VM (1.5.0-b64 mixed mode)
Problematic frame:
C [nvoglnt.dll+0x16499a]
--------------- T H R E A D ---------------
Current thread (0x0af625c8): JavaThread “Thread-3” [_thread_in_native, id=3484]
Other Threads:
0x00a84af0 VMThread [id=2896]
0x00ab4eb0 WatcherThread [id=2056]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
def new generation total 576K, used 331K [0x02ad0000, 0x02b70000, 0x02fb0000)
eden space 512K, 62% used [0x02ad0000, 0x02b204f0, 0x02b50000)
from space 64K, 16% used [0x02b50000, 0x02b529d0, 0x02b60000)
to space 64K, 0% used [0x02b60000, 0x02b60000, 0x02b70000)
tenured generation total 2112K, used 1764K [0x02fb0000, 0x031c0000, 0x06ad0000)
the space 2112K, 83% used [0x02fb0000, 0x03169028, 0x03169200, 0x031c0000)
compacting perm gen total 8192K, used 7653K [0x06ad0000, 0x072d0000, 0x0aad0000)
the space 8192K, 93% used [0x06ad0000, 0x07249580, 0x07249600, 0x072d0000)
No shared spaces configured.
[quote]When closing the window, the demo crashes (consistently) , but using Escape or Q there seems to be no problem!
[/quote]
Thanks for this insight. The problem is that in 1.1 b08 we changed the semantics of Animator.stop(); if it is called from the AWT event queue thread, it returns immediately rather than waiting for the animation thread to terminate, because there might be hidden dependencies between the animation thread and the AWT event queue thread (in particular, in the case where a GLJPanel is being used). This was therefore a bug in the JOGL demos. I’ve just checked in fixes to all of them to run the windowClosing code on another thread, and it looks like this solves the problem. I can’t think of a way to make this work more automatically, unfortunately. Take a look at the revised jogl-demos code and see if that structure of calling Animator.stop() and System.exit() on a separate thread solves the crash on exit in your application.
To solve issues with crashes upon exit with Ctrl-C, you could add a ShutdownHook which calls Animator.stop().
)