---- Reported by delwarl 2004-11-01 22:41:20 ---- Opening up a second JFrame & GLCanvas with a Menu action causes an EXCEPTION_ACCESS_VIOLATION on Windows 2k with ATI hardware & drivers. The problem does not occur with nVidia hardware under Windows or with ATI hardware under Mac OS X. The latest beta (1.1b06) does not solve the problem. A simple test app can be downloaded from the associated URL (BuggyFrame.zip). An unexpected exception has been detected in native code outside the VM. Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x24F8A703 Function=DrvSetContext+0x11313 Library=E:\WINNT\system32\atioglxx.dll at net.java.games.jogl.impl.windows.WGL.wglCreateContext(Native Method) at net.java.games.jogl.impl.windows.WindowsGLContext. choosePixelFormatAndCreateContext (WindowsGLContext.java:495) ... ---- Additional Comments From kbr 2005-01-28 19:05:39 ---- Created an attachment Copy of submitter's test case ---- Additional Comments From kbr 2005-01-28 19:12:23 ---- This doesn't crash on my machine but the creation of the second GLCanvas does fail with a GLException indicating that the pixel format of the second window could not be set. This is almost certainly due to poor multithreading behavior in ATI's drivers and interaction with the new dummyGL code; the question is whether a good workaround can be found. ---- Additional Comments From kbr 2005-01-30 17:10:38 ---- The root cause of this bug was not the new DummyGL code, but severe bugs in ATI's OpenGL drivers where it appears that if an OpenGL context is ever made current on more than one thread during the lifetime of an application, problems begin to occur such as the SetPixelFormat call failing on the just the next newly-created HDC, or all subsequent SetPixelFormat calls failing on all subsequently-created HDCs. This was occurring because the single-threaded ATI workaround's automatic detection mechanism was not being enabled until the first time a context was made current, but by then it was typically too late; the context was made current on the end user's thread during e.g. Frame.show(), and if it was ever made current on another thread (like the AWT event queue thread, which is where all OpenGL operations are performed when the single-threaded workaround is enabled) then the problems would begin. The failure has only been seen on Windows so far; ATI's drivers on X11 seem to be better behaved. The workaround is to check for the presence of ATI's drivers very early during JOGL's initialization, by looking in the system directory for atioglxx.dll, and enabling the single-threaded workaround if it was found. This workaround causes the attached test case to work properly. ---- Additional Comments From kbr 2005-01-30 17:13:44 ---- *** Issue 130 has been marked as a duplicate of this issue. *** --- Bug imported by sgothel@jausoft.com 2010-03-24 07:47 EDT --- This bug was previously known as _bug_ 118 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=118 Imported an attachment (id=27) Unknown bug field "has_duplicates" encountered while moving bug <has_duplicates> <bug_id>130</bug_id> <who>kbr</who> <when>2005-01-30 17:13:44</when> </has_duplicates> CC member delwarl does not have an account here The original submitter of attachment 27 [details] is unknown. Reassigning to the person who moved it here: sgothel@jausoft.com.