Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 176839 - x11-libs/libxcb has tightened locking requirements, numerous applications fail
Summary: x11-libs/libxcb has tightened locking requirements, numerous applications fail
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo X packagers
: 240440 249670 (view as bug list)
Depends on:
Blocks: 174434
  Show dependency tree
Reported: 2007-05-02 18:17 UTC by Dale Pontius
Modified: 2009-09-13 08:06 UTC (History)
17 users (show)

See Also:
Package list:
Runtime testing required: ---

libxcb-1.0 ebuild with sloppy-lock flag (libxcb-1.0-r1.ebuild,1.29 KB, text/plain)
2007-06-05 16:44 UTC, Peter Fern
sloppy lock patch from Novell (libxcb-1.0-sloppy_lock.patch,1.27 KB, patch)
2007-06-05 16:46 UTC, Peter Fern
Details | Diff
libxcb-no-assert-on-lock.patch (libxcb-no-assert-on-lock.patch,841 bytes, patch)
2007-06-18 01:21 UTC, Russell Harmon
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dale Pontius 2007-05-02 18:17:23 UTC
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, and

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:
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.)
Comment 1 Peter Fern 2007-06-05 16:44:15 UTC
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.
Comment 2 Peter Fern 2007-06-05 16:46:54 UTC
Created attachment 121266 [details, diff]
sloppy lock patch from Novell

sloppy lock patch for ${FILESDIR} for previously attached ebuild
Comment 3 Dale Pontius 2007-06-07 18:43:53 UTC
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.
Comment 4 Ryan Hill (RETIRED) gentoo-dev 2007-06-11 00:35:34 UTC
don't close bugs until we actually have the fix in portage ;)
Comment 5 Peter Fern 2007-06-11 12:24:52 UTC
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.
Comment 6 Russell Harmon 2007-06-18 01:21:11 UTC
Created attachment 122380 [details, diff]

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.
Comment 7 Mart Raudsepp gentoo-dev 2007-11-16 21:44:51 UTC
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>

* 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
Comment 8 Daniele C. 2008-01-05 12:47:03 UTC
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.
Comment 9 Donnie Berkholz (RETIRED) gentoo-dev 2008-01-08 23:35:53 UTC
Yeah, we're working on that.
Comment 10 Jeroen Roovers (RETIRED) gentoo-dev 2008-11-07 03:04:50 UTC
*** Bug 240440 has been marked as a duplicate of this bug. ***
Comment 11 Jeroen Roovers (RETIRED) gentoo-dev 2008-12-03 15:50:01 UTC
*** Bug 249670 has been marked as a duplicate of this bug. ***
Comment 12 Martin von Gagern 2009-04-19 11:22:57 UTC
One of the apps likely to crash seems to be kwin. There is an upstream bug at 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?
Comment 13 Rémi Cardona (RETIRED) gentoo-dev 2009-09-13 08:06:08 UTC
All the requires patches have been put in upstream libxcb. Closing fixed.