Oh goodie. I decided to try the new xcb stuff so I turned on the xcb use flag in libX11 and mesa just to find out that java from sun does not work with it. Proprietary software is so much fun. Luckily a change is happening for the better as all of Sun’s java implementation will be released under the GPL in the future.
java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Have you tried Java 1.6?
This was a bug in the open-source libXi library, which has been fixed upstream.
Proprietary software considered harmful, certainly, but not actually the source of the problem this time. 🙂
Apparently this patch ‘solves’ that problem:
http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/x11-libs/libxcb/xcb_xlib-no-assert-on-lock.patch
I’m not sure how safe or correct it is, but it allows broken apps to run.
I have tried 1.6 and it did not work either.
What does the xcb USE flag do? I see it mentioned now with the use of compiz-fusion.
Actually, it is a Java bug. That patch just disables XCB’s equivalent to segfaulting on a double-free.
See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373
The gist of it is:
1. Java (including 1.6) is statically linked against a VERY old libXext compiled with threading off.
2. Java dynamically links against the modern libX11 with threading enabled and, when using the XCB version, XML-parser-like strictness.
3. If Java detects the Xinerama X extension, it does some calls to figure out how the Xinerama desktop is put together… which causees the problem.
4. The problem exists because the un-threaded libXext doesn’t bother to acquire the lock but the XCB-backed threaded Xlib is then asked to release the lock and cries foul over it’s equivalent of a double-free.
To patch away XCB’s strictness is like patching away XML’s strictness or telling the Linux kernel to not throw segfaults if one program messes with another program’s memory. You’re just asking for trouble in the long run.
According to that bug page, one of the Java people is working on solving the problem but, until they do, I’d suggest the following solution which someone on the bug page suggested instead:
Run this sed line (adapt the path, obviously) so that Java doesn’t detect Xinerama and doesn’t call the problem code:
sed -i ‘s/XINERAMA/FAKEEXTN/g’ /opt/sun-jdk-1.6.0.02/jre/lib/amd64/xawt/libmawt.so
You’re genius my friend. This solution solved my problem with some java apps.
WOW! Gotta say that fixed my java problems, Thanks!!!!!!
Running Java on Linux has been the most frustrating experience I have had since I switched over from using Windows full time.
Thanks for this workaround, this solved a ton of issues for me.
This thread: http://forums.gentoo.org/viewtopic-p-4547777.html?sid=5877773e911fcf3de235b3c31414ad26
Has a handy little java program you can compile and run in order to test the bugfix.