As discussed in the libX11/XCB mailinglist and bugzilla - https://bugs.freedesktop.org/show_bug.cgi?id=20708 - http://lists.freedesktop.org/archives/xcb/2011-March/006842.html there is a stall when accessing OpenGL and X11 in a multithreaded manner (as we do at least with NEWT). The affected version are - libX11 1.4.2 - libxcb 1.7 The fix seems to be in the libX11 master - fd85aca7a616c595fc17b2520f84316a11e8906f (14 Mar 2011) and incl. in the upcoming libX11 version 1.4.3 I currently build libX11/libxcb binaries and will verify w/ those later on. ~Sven
Reproduced on jenkins slave w/ ubuntu 11.04 and my dev machine. Can only be avoided by a proper bugfix, or extensive X11 Display locking, which we actually try to avoid to benefit from multithreading - and support it.
Diff tested locking strategies (avoiding the libX11/xcb bug): 1) OK: no XInitThreads, lock AWT, lock X11 2) NO: no XInitThreads, lock X11 (xcb assert) 3) NO: XInitThreads, no lock (hang ..) 4) OK XInitThreads, lock X11 (hang ..)
Created attachment 259 [details] stack traces ..
Sadly the libX11 'fix' fd85aca7a616c595fc17b2520f84316a11e8906f (14 Mar 2011) doesn't solve the issue .. as one reviewer already learned (bug was reopened).
Created attachment 260 [details] ubuntu 10.10 64bit libX11.so 1.3 and libxcb.so 1.5 .. ubuntu 10.10 64bit libX11.so 1.3 and libxcb.so 1.5 .. tested those against ubuntu 11.04 64bit, which removes the stalling bug 502
.. see attachment 260 [details] - working w/ older libX11/libxcb
Well, actually it's a workaround not a fix, which would be a patch in libX11/libxcb. http://jogamp.org/git/?p=jogl.git;a=commit;h=56e46acce6d26e0fdc2fd317649b11f1f71f621a Woraround for bug 502: X11/NEWT Stalling due to libX11/XCB Multithreading bug (libX11 1.4.2, libXCB 1.7; ubuntu 11.04, ..) - set the boolean property 'nativewindow.x11.mt-bug' to 'true', indicating the erroneous libX11/libXCB behavior. This will enable extensive X11 locking even in NEWT.
Since libX11/xcb doesn't seem to be fixed anytime soon, a true workaround has to be reached w/o 'over locking'.
It turns out that the race condition is related to the parallel X11 Display connection usage of GLX/OpenGL and event dispatching. This workaround utilizes 2 X11 Display handles, one for windowing/OpenGL and one for event dispatching. This approach allows us to cont. multithreading use w/o locking the display and works on both implementations, the old bug-free libX11 and the 'new' buggy one. Downside is the little resource overhead of the 2nd X11 Display connection .. well.