Yes, I also get the occasional VM crashes. And the likelyhood that I’ll crash on startup seems to increase as I run the app over and over.
I can confirm the crash on repeately runs of the jogl application, with or without ATI workarounds enabled.
I tried to run JOGL on j2 5.0 b3 and it crashes almost everytime. In 1.4.2 the crashes are sporadic but more common if you try to run the app two times straight with a short dealy between them.
The behaviour cannot be reproduced everytime I try to crash it 
Hi
FWIW, I have just tried an earlier GL4Java version of the www.digiturf.com “enhanced” race viewer on an IBM thinkpad with ATI Mobility Radeon 7500 and it too stops after the first frame, with VM crash etc., just like the JOGL version. This is with the latest drivers from IBM.
Looks like this problem is not limited to JOGL?
Kevin
The drivers are well behind the latest ATI ones unfortunately. Expect all sorts of trouble.
Cas
[quote]Here is the complete output from the program. I added the two Entering/Leaving lines within the display() method.
CANVAS GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
CANVAS GLU IS: net.java.games.jogl.impl.GLUImpl
Using ATI workaround of dispatching display() on event thread
INIT GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: RAGE 128 Pro Ultra x86/SSE2
GL_VERSION: 1.2.1716 WinXP Release
glLoadTransposeMatrixfARB() supported: true
Entering display()
Leaving display()
[/quote]
Thanks. This is helpful but I still don’t know what could be happening. None of the calls being made in the stack trace you attached to the bug report should be blocking calls; the EventQueue thread should complete its notifyAll() and the Animator thread should resume after that. Could you take a few more thread dumps and see whether all of the threads are in the same state every time? Also, there aren’t any exceptions being thrown?
[quote]FWIW, I have just tried an earlier GL4Java version of the www.digiturf.com “enhanced” race viewer on an IBM thinkpad with ATI Mobility Radeon 7500 and it too stops after the first frame, with VM crash etc., just like the JOGL version. This is with the latest drivers from IBM.
Looks like this problem is not limited to JOGL?
[/quote]
No, I don’t think it is. I was able to reproduce the reshape / corruption bugs people reported against JOGL with GL4Java. However, the new ATI_WORKAROUND code addressed the issue on the machines I had available to test with.
I tried running the Gears demo on a Windows 98 machine with an ATI Rage Pro and probably old drivers and the demo came up OK, but the VM crashed on the first resize regardless of whether the ATI_WORKAROUND property was set to true or false. Visual C++ wasn’t available to try to debug the issue further.
I’ll try to run some tests with a more recent OS and drivers.
[quote]I tried running the Gears demo on a Windows 98 machine with an ATI Rage Pro and probably old drivers and the demo came up OK, but the VM crashed on the first resize regardless of whether the ATI_WORKAROUND property was set to true or false. Visual C++ wasn’t available to try to debug the issue further.
I’ll try to run some tests with a more recent OS and drivers.
[/quote]
For reference, DxDiag reports this about the display on this machine:
System Information
Time of this report: 7/27/2004, 09:09:13
Machine name: KDULING-PC
Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 1 (2600.xpsp2.030422-1633)
Language: English (Regional Setting: English)
System Manufacturer: Dell Computer Corporation
System Model: OptiPlex GX240
BIOS: Default System BIOS
Processor: Intel® Pentium® 4 CPU 2.20GHz
Memory: 512MB RAM
Page File: 281MB used, 968MB available
Windows Dir: C:\WINDOWS
DirectX Version: DirectX 9.0b (4.09.0000.0902)
DX Setup Parameters: Not found
DxDiag Version: 5.03.0001.0902 32bit Unicode
Display Devices
Card name: 16MB ATI Rage 128 Ultra
Manufacturer: ATI Technologies Inc.
Chip type: RAGE128 PRO II, (AGP 4X/PCI)
DAC type: Internal DAC (350Mhz)
Device Key: Enum\PCI\VEN_1002&DEV_5446&SUBSYS_04081002&REV_00
Display Memory: 16.0 MB
Current Mode: 1600 x 1200 (32 bit) (85Hz)
Monitor: Plug and Play Monitor
Monitor Max Res: 1600,1200
Driver Name: ati2dvaa.dll
Driver Version: 6.13.0010.5004 (English)
DDI Version: 8
Driver Attributes: Final Retail
Driver Date/Size: 1/11/2002 00:23:06, 318080 bytes
WHQL Logo’d: n/a
WHQL Date Stamp: n/a
VDD: n/a
Mini VDD: ati2mtaa.sys
Mini VDD Date: 1/11/2002 00:22:10, 295168 bytes
Device Identifier: {D7B71EE2-1706-11CF-3E60-0224A2C2CB35}
Vendor ID: 0x1002
Device ID: 0x5446
SubSys ID: 0x04081002
Revision ID: 0x0000
Revision ID: 0x0000
Video Accel: ModeMPEG2_C ModeMPEG2_D
Deinterlace Caps: n/a
Registry: OK
DDraw Status: Enabled
D3D Status: Enabled
AGP Status: Enabled
This is a single run with two thread dumps taken about 20 seconds apart.
diff dump1.txt dump2.txt
5c5
< “Thread-1” prio=5 tid=0x02db6708 nid=0x1ca0 in Object.wait() [465f000…465fd8c]
“Thread-1” prio=5 tid=0x02db6708 nid=0x1ca0 runnable [465f000…465fd8c]
9c9
< - locked <0x10010f20> (a java.awt.EventQueue$1AWTInvocationLock)
- locked <0x10081b58> (a java.awt.EventQueue$1AWTInvocationLock)
I still don’t see what is happening. The AWT event queue thread should be doing a notifyAll() on the invocation lock which should wake up the Animator thread. notifyAll() is not a blocking operation.
If I could run on your machine, I would instrument the JOGL code in GLCanvas.displayImpl() and see whether displayImpl() is getting called more than once while the screen remains white, and whether the code in the Runnable that is being passed over to the AWT event queue thread is being run.
For anyone who is interested the problem is at the start of invokeGL in the following code:
if (!isRealized() ||
willSetRenderingThread ||
(renderingThread != null &&
renderingThread != currentThread)) {
On my nvidia machine where the ATI workaround works the following is happening:
!isRealized: false
willSetRenderingThread: false
renderingThread != null: false
renderingThread != currentThread: true
On my ATI machine where the workaround does not work looks like this:
!isRealized: false
willSetRenderingThread: false
renderingThread != null: true
renderingThread != currentThread: true
This means that invokeGL is returning before any rendering can occure.
I just emailed GKW privately about this issue but I think there is probably a race condition in the auto-detection of the ATI_WORKAROUND flag. If you specify -DATI_WORKAROUND=true or -DATI_WORKAROUND=false, it should have different behavior than leaving the system property unspecified. The issue is that the component’s rendering thread is being specified before it is detected that the single-threaded workaround should take effect, so when the workaround kicks in the context is already current on another thread. I’ll need to think about this some more. Hopefully GKW’s fix for the other bug (needing to manually create a dummy OpenGL context) can be used to fix this as well, by finding the GL_VENDOR of the dummy context.
[quote]I just emailed GKW privately about this issue but I think there is probably a race condition in the auto-detection of the ATI_WORKAROUND flag. If you specify -DATI_WORKAROUND=true or -DATI_WORKAROUND=false, it should have different behavior than leaving the system property unspecified.
[/quote]
I’ve just upgraded to jogl1.1b04 and my ATI 9700 really prefer me to put a -DATI_WORKAROUND=true rather than leaving it unspecified! So Ken you may be right!
We think we found the problem. Hopefully the next release will be rock solid for everyone.