jogl
  1. jogl
  2. JOGL-118

EXCEPTION_ACCESS_VIOLATION on show of 2nd canvas (ATI-specific)

    Details

    • Issuezilla Id:
      118

      Description

      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)

      ...

        Activity

        Hide
        kbr added a comment -

        Created an attachment (id=33)
        Copy of submitter's test case

        Show
        kbr added a comment - Created an attachment (id=33) Copy of submitter's test case
        Hide
        kbr added a comment -

        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.

        Show
        kbr added a comment - 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.
        Hide
        kbr added a comment -

        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.

        Show
        kbr added a comment - 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.
        Hide
        kbr added a comment -
            • Issue 130 has been marked as a duplicate of this issue. ***
        Show
        kbr added a comment - Issue 130 has been marked as a duplicate of this issue. ***

          People

          • Assignee:
            jogl-issues
            Reporter:
            delwarl
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: