Red Hat Bugzilla – Full Text Bug Listing
|Summary:||xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.|
|Product:||[Fedora] Fedora||Reporter:||Matěj Cepl <mcepl>|
|Component:||libX11||Assignee:||Søren Sandmann Pedersen <sandmann>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||8||CC:||adilger.redhat, a.efremov, cra, darrellpf, dave, dhaval.giani, dwalisser, fedora, goeran, hdegoede, horsley1953, jan.public, joachim.backes, kem, k.georgiou, kmaraas, linux, lvanek, me, mszpak, mtakahashi, nojunk311, redhat.com, rich, stuart.i.campbell, tdik123, tjd, xgl-maint|
|Target Milestone:||---||Keywords:||Patch, Reopened, Tracking|
|Fixed In Version:||1.1-1.1||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-09-07 15:50:16 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||300991, 301691, 310841, 381861, 382521, 386321, 391781|
Description Matěj Cepl 2007-11-19 07:42:53 EST
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)
Comment 3 Hans de Goede 2007-11-19 11:03:41 EST
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.
Comment 4 Matěj Cepl 2007-11-27 04:24:35 EST
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 http://www.linuxfromscratch.org/patches/blfs/svn/libxcb-1.0-sloppy_lock-1.patch
Comment 5 Matěj Cepl 2007-11-27 04:26:49 EST
The patch is apparently from OpenSuSE package http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/suse/src/xorg-x11-libxcb-7.2-33.src.rpm
Comment 6 Matěj Cepl 2007-11-27 08:58:52 EST
*** Bug 254144 has been marked as a duplicate of this bug. ***
Comment 7 Tom Horsley 2007-11-27 09:15:04 EST
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 them off.
Comment 8 Matěj Cepl 2007-11-27 09:54:28 EST
There is so much humour about this bug, that I call it real.
Comment 9 Richard Dawe 2007-12-02 09:01:05 EST
Affects openoffice.org-writer-2.3.0-6.6.fc8 on x86_64: [rich@meelo ~]$ oowriter &  13835 [rich@meelo ~]$ swriter.bin: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Comment 10 Søren Sandmann Pedersen 2007-12-04 17:42:54 EST
Upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=11390 We should apply this patch, but without the environment variable. xlib certainly can't abort applications that worked before.
Comment 11 Andreas Dilger 2007-12-07 01:00:57 EST
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 error reports.
Comment 12 Richard Dawe 2007-12-08 02:33:33 EST
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.
Comment 13 Tom Horsley 2007-12-08 20:36:42 EST
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 :-).
Comment 14 Matěj Cepl 2008-01-10 07:46:15 EST
*** Bug 427348 has been marked as a duplicate of this bug. ***
Comment 15 Matěj Cepl 2008-01-10 07:47:02 EST
*** Bug 386321 has been marked as a duplicate of this bug. ***
Comment 16 Matěj Cepl 2008-01-10 07:48:07 EST
*** Bug 391781 has been marked as a duplicate of this bug. ***
Comment 17 Matěj Cepl 2008-01-10 07:48:31 EST
*** Bug 397241 has been marked as a duplicate of this bug. ***
Comment 18 Matěj Cepl 2008-01-23 19:46:05 EST
*** Bug 372071 has been marked as a duplicate of this bug. ***
Comment 19 Matěj Cepl 2008-01-31 11:32:01 EST
*** Bug 394041 has been marked as a duplicate of this bug. ***
Comment 20 Matěj Cepl 2008-02-11 05:57:40 EST
*** Bug 432331 has been marked as a duplicate of this bug. ***
Comment 21 Göran Uddeborg 2008-03-09 16:17:59 EDT
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α.
Comment 22 Kjartan Maraas 2008-03-09 16:56:30 EDT
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.
Comment 23 Göran Uddeborg 2008-03-26 16:53:38 EDT
Still broken in F9β (libxcb-1.1-2.fc9).
Comment 24 Göran Uddeborg 2008-04-01 17:30:00 EDT
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.
Comment 25 Jack Deslippe 2008-04-15 17:34:08 EDT
*** Bug 442534 has been marked as a duplicate of this bug. ***
Comment 26 Jesse Keating 2008-04-18 11:18:02 EDT
Moving to the X blocker.
Comment 27 Ngo Than 2008-04-18 13:20:36 EDT
*** Bug 382521 has been marked as a duplicate of this bug. ***
Comment 28 Adam Jackson 2008-04-22 12:01:11 EDT
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.
Comment 29 Thomas Vander Stichele 2008-06-03 12:19:48 EDT
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 PM CEST 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] #3 /usr/lib/vmware/lib/libXrender.so.1/libXrender.so.1(XRenderQueryFormats+0x109) [0x1e2969] #4 /usr/lib/vmware/lib/libXrender.so.1/libXrender.so.1(XRenderFindFormat+0x4c) [0x1e2f4c] #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] #7 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0(gdk_draw_pixbuf+0x270) [0x37bc14] #8 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0 [0x38824f] #9 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0(gdk_draw_pixbuf+0x270) [0x37bc14] #10 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0(gdk_pixbuf_render_pixmap_and_mask_for_colormap+0x255) [0x387b34] #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] #14 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0xd1) [0x2ad459] #15 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0 [0x2953a1] #16 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0(g_closure_invoke+0x1b1) [0x295076] #17 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0 [0x2ac6eb] #18 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0(g_signal_emit_valist+0x91e) [0x2abd46] #19 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0(g_signal_emit+0x38) [0x2ac0b8] rpm -q --changelog confirms that this rpm has the sloppy locking patch.
Comment 31 Tom Davidson 2008-07-26 19:47:09 EDT
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?
Comment 32 Tom Horsley 2008-07-27 10:52:44 EDT
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?
Comment 33 Matěj Cepl 2008-07-28 05:08:28 EDT
Apparently the problem is now limited to F8? Could anybody reproduce it on F9 or the current Rawhide?
Comment 34 Mark Locascio 2008-07-28 10:45:59 EDT
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.
Comment 35 Tom Davidson 2008-07-28 12:43:24 EDT
@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.
Comment 36 Tom Davidson 2008-08-01 01:13:17 EDT
Fixed as of libxcb 1.1-1.1, just released. See bug 456824. --Thanks Adam
Comment 37 Matěj Cepl 2008-08-01 08:45:44 EDT
OK, so this bug could be closed as CURRENTRELEASE 1.1-1.1?
Comment 38 Matěj Cepl 2008-09-07 15:50:16 EDT
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.