Bug 118

Summary: EXCEPTION_ACCESS_VIOLATION on show of 2nd canvas (ATI-specific)
Product: [JogAmp] Jogl Reporter: Sven Gothel <sgothel>
Component: coreAssignee: Sven Gothel <sgothel>
Status: VERIFIED FIXED    
Severity: normal    
Priority: P2    
Version: 1   
Hardware: All   
OS: windows   
URL: http://delsci.com/java/BuggyFrame.zip
Type: DEFECT SCM Refs:
Workaround: ---
Attachments: Copy of submitter's test case

Description Sven Gothel 2010-03-24 07:47:03 CET


---- 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.