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 http://www.linuxfromscratch.org/patches/blfs/svn/libxcb-1.0-sloppy_lock-1.patch
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
*** 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 them off.
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 & [5] 13835 [rich@meelo ~]$ swriter.bin: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
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.
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.
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 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.
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.