Bug 150519

Summary:	KDE TRUNK (4) won't run with unpatched XCB
Product:	[I don't know] kde	Reporter:	James Richard Tyrer <tyrerj>
Component:	general	Assignee:	Unassigned bugs <unassigned-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	major	CC:	l.lunak
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Log of attempt to run KDE 4 from Xterm

Description James Richard Tyrer 2007-10-05 22:19:35 UTC

Version:           TRUNK (using KDE Devel)
Installed from:    Compiled sources
Compiler:          GCC 4.2.1 
OS:                Linux

When attempting to start KDE-4 with: "startkde" in an Xterm in an X session it fails with this error:

xcb_xlib.c:50: xcb_xlib_unlock: Assertion c->xlib.lock failed

After some Google research, I found this:

http://osdir.com/ml/debian.devel.announce/2006-11/msg00010.html

Ideally, you will not notice any change at all.  However, Xlib/XCB
includes some additional code to check for bugs in calling software.  If
you encounter a problem, you will most likely just see an application
disappear, due to having triggered an assertion and aborted.  If you ran
the application from a terminal, you can look there to see error output
and get more details; otherwise, look at ~/.xsession-errors.  The
assertions look like one of these:

    xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.
    xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

Both of these represent bugs in a caller of libX11, and *not* in libX11
or libxcb.  The first assertion means that a caller attempted to lock
the display while already locked.  The second assertion means that a
caller attempted to unlock the display without having it locked.  If you
encounter such bugs, please report a bug against the offending software
(*not* libx11-6 or libxcb)

Comment 1 James Richard Tyrer 2007-10-05 22:27:02 UTC

Created attachment 21760 [details]
Log of attempt to run KDE 4 from Xterm

IIUC, this is a KDE bug.

Comment 2 James Richard Tyrer 2007-10-05 22:27:34 UTC

IMHO, this is a major bug.

Comment 3 Lubos Lunak 2007-12-07 12:23:23 UTC

To my knowledge neither KDE nor Qt lock the X connection, so this looks like a bug in some of the underlying libraries (including other X11 libraries, I suggest updating). Especially given that I don't see any such problem here.

Comment 4 James Richard Tyrer 2007-12-08 06:48:13 UTC

Re: Comment #3

This seems quite possible.  It is a known bug in Sun Java for instance.

Do you think that the 'startkde' script should set:

LIBXCB_ALLOW_SLOPPY_LOCK="true"

and then we should consider the issue resolved?

Comment 5 Lubos Lunak 2007-12-08 18:54:16 UTC

I don't see why KDE should do that. More than just KDE is affected, and X libraries should not have affected backwards compatibility in such a bad way in the first place. I suggest asking your distribution to patch X libraries to merely issue a warning (like e.g. openSUSE does).
If you can identify specific places in KDE which cause this problem, please report a bug for them, but I don't see this generic bugreport to be a KDE problem (especially given that in my KDE4 log there's not a single message about this, so this really looks like a problem in underlying libraries in your system).