Created attachment 290 [details] Log and informations GLWindow.setVisible and GLWindow.setSize internally cause the exception "wglShareLists(0x10002, 0x20003) failed: werr 0". This happens when a GLWindow is using a shared context (setSharedContext) and it is running in a separate thread than original opengl context (own thread or a new Animator). Windows 7 x64 with NVidia GTX 260 (Driver: 285.62) and JOGL 544 See attachments for more details.
Created attachment 291 [details] TestSharedContextListNEWT.java Modify existing junit test to reproduce the exception. Failure rate on my machine > 75% (so please run more than once)
Created attachment 292 [details] TestSharedContextListNEWT2.java Similar unit test than TestSharedContextListNEWT but sharing context from a GLWindow. Failure rate on my machine > 75% (so please run more than once)
reproduce on win7 64bit, latest source code - investigating.
Commit 97218b88af9113740b3704a3666d7356cdc83cd0 log: Fix Bug 527: Creating a context w/ shared context, while the latter is in use (threading) Bug 527 describes the situation where wglShareLists() fails (throws exception) while the shared context is in use by another thread (some Animator). It was reported by Jerome Jouvie. The exception happens not everytime, but at least around 20% on manual tests I have performed on the Windows platform. The context in question are all JOGL's GL2, which natively where bound to an OpenGL 3.0 profile. The WGL_ARB_create_context spec says http://www.opengl.org/registry/specs/ARB/wgl_create_context.txt: +++ Future versions of OpenGL may only support being added to a share group at context creation time. Specifying such a version of a context as either the <hglrc1> or <hglrc2> arguments to wglShareLists will fail. wglShareLists will return FALSE, and GetLastError will return ERROR_INCOMPATIBLE_DEVICE_CONTEXTS_ARB. +++ Hence the 1st patch was to remove 'wglShareLists()' usage in case we use the new WGL_ARB_create_context context creation method. Even though this is a desired change, and works in general, it didn't fix the issue. It seems that the shared context, which is passed @ new context creation, cannot be used while it is in use itself in another thread. This conclusion leads to the actual fix, ie. locking the shared context while creating the new context which shares it. Manual tests using this patch could not reproduce this issue (40 attempts). Test: TestSharedContextListNEWT2