Recently libxcb, along with libX11 and others layered atop it became available in stable. Apparently libxcb has tightened locking semantics significantly, because numerous applications began failing with symptoms like: python: xcb_xlib.c:50: xcb_xlib_lock: Assertion `!c->xlib.lock' failed. There are at least 2 other Gentoo bugs filed against this, https://bugs.gentoo.org/show_bug.cgi?id=156353 and http://bugs.gentoo.org/show_bug.cgi?id=174434 Reproducible: Always Steps to Reproduce: 1. Set "xcb" in /etc/make.conf USE flags 2. Rebuild as needed, notably libX11, mesa, cairo, etc 3. Try to run "broken" application, such as Sun jdk, Cadence IC Craftsman 6.1.1, etc. Actual Results: Application fails to start, giving a message like: python: xcb_xlib.c:50: xcb_xlib_lock: Assertion `!c->xlib.lock' failed. (Some applications fail on unlock, instead.) Expected Results: Application should have started, and run. Stated resolution is that clients need to fix their locking, those fixes are taking place, and technically that is correct. I have personally found problems with SOME application on every platform I've built xcb/libX11 on. There are 2 problems with the "wait for fixed clients" strategy: First, testing will be reduced, because many will just set "-xcb" in make.conf and wait for others to flush out the problems. Second, some of us need to use closed-source software. I have personally found the problem with Cadence IC Craftsman 6.1.1 tools, and while I am working with them to get this resolved, the wheels grind slowly. For the moment I have set "/etc/portage/env/x11-libs/libxcb-1.0" to 'CFLAGS="-O2 -march=pentium3 -fomit-frame-pointer -pipe -DNDEBUG"' in order to work around the locking problems, and allow me to run Cadence. But now I'm testing NOTHING for the enhanced locking semantics, and providing no further feedback. There is another fix identified here: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/87390 It's about halfway down the page, look for "LIBXCB_ALLOW_SLOPPY_LOCK". Apparently Debian has a patch that relaxes the locking semantics ONLY when the environment variable is set. This way by default you get the testing with the tighter locking semantics, plus a way to run "broken" software until it's fixed. I'm sorry I haven't dug out the exact Debian patch, but I'm not familiar with their setup, and for that matter I'm only marginally familiar with Bugzilla. Gentoo would be better off including this patch into libxcb, even if it takes a USE flag to apply it. In the long run "industrial users" whose jobs require proprietary software may be required to run back-level versions of X11, perhaps the entire OS. At the same time, that proprietary software will not be getting the feedback necessary to correctly fix the problem. (Sun is MUCH better connect to Open Source development than most proprietary software running on Linux.)
Created attachment 121264 [details] libxcb-1.0 ebuild with sloppy-lock flag I've attached an updated ebuild including the lazy locking patch from Novell which allows enabling of lazy locks by setting the LIBXCB_ALLOW_SLOPPY_LOCK use flag. This is not an optimal solution, but this method allows users to enable it selectively.
Created attachment 121266 [details, diff] sloppy lock patch from Novell sloppy lock patch for ${FILESDIR} for previously attached ebuild
As far as I'm concerned, (as the originator) this problem can be considered FIXED, though I would like to see it pushed out for regular release. I built and tested it against Cadence IC-6.1.1, and found the lock fails happen by default, but go away when I set the LIBXCB_ALLOW_SLOPPY_LOCK=true environment variable. IMHO this is the preferred way to allow use of known-buggy (hopefully reported to the developers) applications while running properly, and perhaps finding new buggy applications to report.
don't close bugs until we actually have the fix in portage ;)
Wow, I just read my description of the previously attached ebuild, I must have been smoking crack (actually, I think it was about 4am). Just for clarity: The above ebuild adds the use flag: 'sloppy-lock' When enabled, the sloppy locking patch from Novell is applied, providing the ability to loosen the locking strategy in libxcb to avoid asserts when the 'LIBXCB_ALLOW_SLOPPY_LOCK' environment variable is present. The ebuild also adds einfo output describing this behaviour and suggesting the possibility to enable it globally via env.d.
Created attachment 122380 [details, diff] libxcb-no-assert-on-lock.patch Here is an alternative patch that I have been using for quite a while now (I don't usually report much because I usually get told to go somewhere else and i'm too lazy to). This one however is probably a worse choice because I *believe* that it removes some of the locking requirements entirely instead of introducing that environment variable to check. Just thought another option and my say that i've been using this for about four months (i think) w/o any problems would be useful.
In the libxcb-1.1 release notes: This release contains several important bug fixes, summarized below. It also contains a patch much like Novell's libxcb-sloppy-lock.diff. <rationale skipped> Enhancements: * Print a backtrace, if possible, on locking assertion failures. * Skip abort() on locking assertions if LIBXCB_ALLOW_SLOPPY_LOCK is set. ... Now if old java would set it up somehow, we might be golden with libxcb-1.1
I am using libxcb-1.1 with the sloppy lock enabled and everything runs fine. Can't it be marked as stable? It is currently keyworded.
Yeah, we're working on that.
*** Bug 240440 has been marked as a duplicate of this bug. ***
*** Bug 249670 has been marked as a duplicate of this bug. ***
One of the apps likely to crash seems to be kwin. There is an upstream bug at http://bugs.kde.org/182462 but reporters seem to come from Gentoo exclusively. So it would be a good thing for Gentoo devs to have a look. Would you deal with this in this report here, or should I file a separate specifically for kwin?
All the requires patches have been put in upstream libxcb. Closing fixed. Thanks
