Red Hat Bugzilla – Bug 390261
xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.
Last modified: 2018-04-11 11:11:25 EDT
Description of problem:
Tracker bug for all bugs with programs failing with the above
Version-Release number of selected component (if applicable):
libX11 on F8 (most likely libX11-1.1.3-4.fc8.i386)
And adding the most famous of them all -- bug 301691
Maybe 310841 should be removed, the problem there us an unhandled X-error
getting thrown, only when printing the error: "xcb_xlib.c:41: xcb_xlib_lock:
Assertion `!c->xlib.lock' failed." Gets printed, if the error is properly caught
and handled by the app, all is fine.
Created attachment 269541 [details]
patch from Linux from scratch
Markus Franke in bug 386321 comment 8 mentinoed patch from Linux from scratch,
which is on
The patch is apparently from OpenSuSE package
*** Bug 254144 has been marked as a duplicate of this bug. ***
Having finally found the consolidated libxcb lock bugzilla, I'd just like to
point out that the assertions are totally bogus (whatever so called logic
is being applied upstream :-).
1. Single threaded programs don't need any steenkin locks, and they are
still thread safe.
2. Multithreaded programs which restrict all X activity to a single thread
don't need any locks either, and are also thread safe (as far as X is
concerned, anyway). For one example, this is a model Qt enforces.
It is conceivable that libxcb could detect case 1 and avoid the assertions,
but it is much less likely that it could detect case 2 in any reasonable
fashion, therefore my conclusion that the assertions are completely bogus
and should be removed, or at least the idea of an environment variable
like the sloppy lock patch should be inverted so that I have to
do something special to turn the asserts on, not something special to turn
There is so much humour about this bug, that I call it real.
Affects openoffice.org-writer-2.3.0-6.6.fc8 on x86_64:
[rich@meelo ~]$ oowriter &
[rich@meelo ~]$ swriter.bin: xcb_xlib.c:50: xcb_xlib_unlock: Assertion
We should apply this patch, but without the environment variable. xlib certainly
can't abort applications that worked before.
I agree that the current situation is unusable. Since the libxcb RPM update on
October 17th or so I haven't been able to use Java applications. Since I'm in a
new job and I have a new FC8 install I thought it was a configuration problem as
there is no visible error message at all. I'm no newbie at Linux, and I pity
the users that are hitting this problem and haven't even gotten as far as
finding out that this is a common problem.
If the upstream libxcb developers have no concern for end users having working
systems, then hopefully the Fedora maintainers do. If the issue is flagging
applications that are linked incorrectly, then I'd suggest putting a
rate-limited message into the syslog like "application X isn't compiled with
XTHREADS" or something, and have an open bug with that as the summary to collect
I've put a version of libxcb with the sloppy locking patch here:
<http://yum.phekda.org/fedora/F8/>. No environment variable is needed -- sloppy
locking is always enabled. oowriter works again for me.
Note that I only have an x86_64 build available. On other platforms "rpmbuild
--rebuild libxcb-1.0-3.1richdawe.fc8.src.rpm" and then install the newly built rpms.
Just to head off confusion, I'll point out a note got added to redhat bug 11390
which almost certainly belongs here instead (the freedesktop bug is 11390 :-).
It says 1.0-4 libxcb was released with the asserts removed (and there was
much rejoicing :-).
*** Bug 427348 has been marked as a duplicate of this bug. ***
*** Bug 386321 has been marked as a duplicate of this bug. ***
*** Bug 391781 has been marked as a duplicate of this bug. ***
*** Bug 397241 has been marked as a duplicate of this bug. ***
*** Bug 372071 has been marked as a duplicate of this bug. ***
*** Bug 394041 has been marked as a duplicate of this bug. ***
*** Bug 432331 has been marked as a duplicate of this bug. ***
As comment 13 says, there is a patched version available for F8. But isn't the
patch needed for rawhide/F9 too? I see these problems again with
libxcb-1.1-1.fc9 from F9α.
Yeah, I see this almost every time I update from rawhide. Evolution has a
tendency to die during yum update with a backtrace pointing to this problem.
Still broken in F9β (libxcb-1.1-2.fc9).
Some people reading this bug might appreciate this little tip: If you use libxcb
1.1 (test/rawhide) you can set the environment variable LIBXCB_ALLOW_SLOPPY_LOCK
to 1 to avoid the crash. Libxcb will still print a traceback, but the
application will not crash.
Subject to change as patches are made to libxcb, obviously.
*** Bug 442534 has been marked as a duplicate of this bug. ***
Moving to the X blocker.
*** Bug 382521 has been marked as a duplicate of this bug. ***
Right, sick of fighting this bug, and pretty well convinced that xcb's behaviour
here is just dumb.
Sloppy locking always enabled in libxcb 1.1-3.fc9 and newer.
Are you sure it's enabled ? I'm running FC9, with:
[thomas@level flu]$ rpm -qi libxcb
Name : libxcb Relocations: (not relocatable)
Version : 1.1 Vendor: Fedora Project
Release : 4.fc9 Build Date: Tue 22 Apr 2008 07:31:20
but vmware still crashes:
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xd93767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xd93831]
#2 /usr/lib/libX11.so.6(_XReply+0x244) [0xc97f64]
#5 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0 [0x3ab180]
#6 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0 [0x3abd2c]
#8 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0 [0x38824f]
#11 /usr/lib/vmware/lib/libgtk-x11-2.0.so.0/libgtk-x11-2.0.so.0 [0x823298]
#12 /usr/lib/vmware/lib/libgtk-x11-2.0.so.0/libgtk-x11-2.0.so.0 [0x823586]
#13 /usr/lib/vmware/lib/libgtk-x11-2.0.so.0/libgtk-x11-2.0.so.0 [0x82577e]
#15 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0 [0x2953a1]
#17 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0 [0x2ac6eb]
rpm -q --changelog confirms that this rpm has the sloppy locking patch.
libxcb 1.1-1 was pushed to F8-updates yesterday, apparently to resolve bug 452683.
Unfortunately it doesn't include ajax's patch from comment 28, and so some apps
now crash under F8. (Whereas yesterday they didn't even issue a warning).
Perhaps 1.1-4 could be pushed out to F8?
Yep. I can verify libxcb be busted again. Old motif app I need to access
citrix server is back to dying, but it worked fine before the update. This
app has been busted at least a half dozen times by libxcb, then fixed again
later. What does it take to make the fix stick? Can we storm x.org with
pitchforks and torches and depose the absolute dictators there who refuse
to acknowledge that they are simply dead wrong on this issue?
Apparently the problem is now limited to F8? Could anybody reproduce it on F9 or
the current Rawhide?
Accidentally installed the update to libxcb - 1.1-1.fc8.i386 this morning on F8.
I can verify that everything that used to work with libxcb is broken again
(BOINC, Matlab, etc.), but I can also verify that stuff can still be run by
issuing a command like "export LIBXCB_ALLOW_SLOPPY_LOCK=true; matlab"
It'd be nice to get the fix back in there so we don't have to modify scripts though.
@Matej: F9 should be fine. The problem seems to be that F8's libxcb needed to be
bumped to version 1.1 to avoid upgrade conflicts(see bug 452683). But it was
upgraded from the patched version 1.0-4 (see comment #13 above) to the
*unpatched* 1.1-1, instead of the latest, patched, 1.1-4, thus reintroducing
this bug to F8.
Fixed as of libxcb 1.1-1.1, just released. See bug 456824. --Thanks Adam
OK, so this bug could be closed as CURRENTRELEASE 1.1-1.1?
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution.
Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.
Closing as INSUFFICIENT_DATA.