Bug 390261 - (c->xlib.lock) xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.
xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: libX11 (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Søren Sandmann Pedersen
Fedora Extras Quality Assurance
: Patch, Reopened, Tracking
: 254144 372071 382521 386321 391781 394041 397241 427348 432331 442534 (view as bug list)
Depends On: 300991 java-xcb-lock 310841 381861 382521 386321 391781
Blocks: f9-x-blocker
  Show dependency treegraph
 
Reported: 2007-11-19 07:42 EST by Matěj Cepl
Modified: 2014-06-18 05:09 EDT (History)
28 users (show)

See Also:
Fixed In Version: 1.1-1.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-07 15:50:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch from Linux from scratch (2.36 KB, patch)
2007-11-27 04:24 EST, Matěj Cepl
no flags Details | Diff

  None (edit)
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 2 Matěj Cepl 2007-11-19 07:53:41 EST
And adding the most famous of them all -- bug 301691
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 &
[5] 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.

Note You need to log in before you can comment on or make changes to this bug.