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

more information on
http://lists.debian.org/debian-devel-announce/2006/11/msg00010.html

fcitx's version:
ii fcitx 3.4-1 Free Chinese Input Toy for X (XIM)

See bug 87390; a workaround is in place in Feisty's current package, allowing apps to work. Said workaround will be dropped when Feisty+1 opens.

Per the debian-devel-announce message, please make sure your X libraries are up to date. If you can still reproduce the problem, can you supply a backtrace?

I believe this bug is now fixed in upstream libX11 git.
http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=commitdiff;h=c2f88cdf5cd9c94b77e5bfdac572b5ac06ab4aa8

Currently the plan is to enable xcb for Hardy Heron. Sun has acknowledged the problem in their java, and it's hopefully fixed soon.

Hardy now has 1.1.3, marking as fixed.

I do not think this bug has been satisfactorily fixed. Whenever I try to run Matlab or other java dependent applications such as jconsole I get the following error message:

 xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

Steps to reproduce bug:
Install sun-java6-jdk
Run

$ jconsole

Crashes with the following information:

Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb54fb767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb54fb8b1]
#2 /usr/lib/libX11.so.6(_XReply+0xfd) [0xb555029d]
#3 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0xb56538ce]
#4 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0xb5630067]
#5 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0xb5630318]
#6 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x2f) [0xb563061f]
#7 [0xb5ce6e9d]
#8 [0xb5cdfedd]
#9 [0xb5cdfedd]
#10 [0xb5cdd249]
#11 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/client/libjvm.so [0x621c40d]
#12 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/client/libjvm.so [0x6310378]
#13 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/client/libjvm.so [0x621c2a0]
#14 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/client/libjvm.so(JVM_DoPrivileged+0x363) [0x6272153]
#15 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/libjava.so(Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x3d) [0xb7cf896d]
#16 [0xb5ce6e9d]
#17 [0xb5cdfd77]
#18 [0xb5cdd249]
#19 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/client/libjvm.so [0x621c40d]
jconsole: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted (core dumped)

hasan: it's a bug in java, so you need to use 'LIBXCB_ALLOW_SLOPPY_LOCK=1 $prog'. To "fix" java on your system, look at /usr/share/doc/libx11-6/NEWS.Debian.gz. Due to licensing issues that change cannot be done on the java packages.

 For sun-java5-bin:
sed -i 's/XINERAMA/FAKEEXTN/g'
/opt/sun-jdk-1.5.0.12/jre/lib/i386/xawt/libmawt.so

For sun-java6-bin:
sed -i 's/XINERAMA/FAKEEXTN/g'
/opt/sun-jdk-1.6.0.02/jre/lib/i386/xawt/libmawt.so

The same fix (applied to the appropriate file) might work for other
proprietary JDKs.

On Jan 26, 2008 3:41 PM, Timo Aaltonen <email address hidden> wrote:

> hasan: it's a bug in java, so you need to use
> 'LIBXCB_ALLOW_SLOPPY_LOCK=1 $prog'. To "fix" java on your system, look
> at /usr/share/doc/libx11-6/NEWS.Debian.gz. Due to licensing issues that
> change cannot be done on the java packages.
>
> --
> xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
> https://bugs.launchpad.net/bugs/87947
> You received this bug notification because you are a member of Ubuntu
> CJK Testers, which is a direct subscriber.
>

--
顺颂秋安
Jason, Jijun MA
http://jjmmma.com/
Zhejiang University-Intel Technology Center
College of Computer Science, Zhejiang University, China

Hi,
this problem is also affecting other programs in Hardy.
For example the Citrix ICA Client needs the same work around
export LIBXCB_ALLOW_SLOPPY_LOCK=1

Opera starts only in terminal preceded by:

export LIBXCB_ALLOW_SLOPPY_LOCK=1

(same for Azureus but it is java program...)

posted also in other bug...excuse me for my inexperience!

This is a regression in hardy. Nearly all graphical java programs will fail due to this. Early releases of gutsy had this problem but it was fixed before the release such that a default installation of gutsy did not experience the problem for java programs. Yes, technically it's a bug in Java, but it's been there for quite a while and isn't likely to be fixed in time for 8.04. Please make the necessary corrections for hardy, whether it be turning off this assertion in xcb-xlib, or adding the appropriate env var to the default /etc/bash.bashrc

I can confirm this bug for hardy alpha 5

~~~
$ java -jar GoogleVideoUploader.jar

Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x7f9c5192c97c]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x24) [0x7f9c5192ca84]
#2 /usr/lib/libX11.so.6(_XReply+0x10f) [0x7f9c5218b14f]
#3 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/amd64/xawt/libmawt.so [0x7f9c52690786]
#4 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/amd64/xawt/libmawt.so [0x7f9c526714eb]
#5 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/amd64/xawt/libmawt.so [0x7f9c526717bd]
#6 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/amd64/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x12) [0x7f9c52671a32]
#7 [0x7f9c77ae8878]
java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted (core dumped)

No need to confirm, it's well known. We can't fix old java's though, so either the locking behaviour needs to be changed so that it allows sloppy locks by default.

Please change default to sloppy locks. There are a lot of binary java apps, that need older versions of java (1.3.1 or 1.4.2) and most users will encounter this problem. I know it's not the prefered solution, but it's easy enough to satisfy a lot of people.

What would the consequences be of defaulting to sloppy locks? And are there any change that SUN will actually fix the problem any time soon? I mean, it has now been at least one year since this problem was reported...

Sun will not fix java5/6, but it has already been fixed in icedtea and the upcoming java7. AFAIK there would be no issues if libx11 defaults to sloppy locks, so it should be doable.

I tried to link to the upstream report: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373c bug launchpad doesn't know about sun's bug database (yet).

We are experiencing the same issue as we prepare for our migration to Hardy. Java 5/6 is a requirement for us so I'm anxious to see a resolution to this.

Are you saying that the same work-around used in Gutsy for Java 5/6 will be available in Hardy? Or are you saying if someone makes the fixes to libx11 you will be happy to include them? I just want to make sure I understand and try to see if there is a way to help move the process along.

Hello,

Many people here in Norway (who run Hardy Alpha6) cannot login to their internet bank or do any other internet transactions because the Firefox's Java-plugin does not work. The security and login system is called BankID applet and it requires Sun's Java5/6 (or possibly later) plugin and JavaVM. Unfortunately the BankID does not work with the IcedTea java-7.

You can test the BankID here: http://bankid.no
Clik on the "teste" link to test it. (english explanation is also avail http://bankid.no/index.db2?id=4373 )

Of course, the following (xcb related) workaround does work and BankID applet with Suns JavaVM is happy, but most end users will not understand these commands
$ export LIBXCB_ALLOW_SLOPPY_LOCK=1
$ firefox

So this bug is rather severe.

When will Sun Microsystems release Java7? Will it get into the Hardy before due date.
Am happy to help what ever you ask ;-)

Timo, please revert to sloppy locking and let that be the end of it. The current situation makes no sense at all: Having applications crash because of a _recoverable_ error is just stupid. It seems like an extremely dickish move by the xcb developers (or whoever is responsible for this insanity) to punish end users in order to prove a point to application developers (who, in the case of java, evidently don't even give a shit), especially since they couldn't even be bothered to include a clear warning in their debug messages that this type of leniency was likely to be removed in a later version of the lib. (Of course, even that wouldn't have prevented "masked" bugs of this type, the correct way to change their locking semantics would have been to introduce a new locking mechanism and deprecate the old one, giving developers a chance to fix their programs and not leaving end users baffled as to why their apps keep crashing)

No adverse effects are to be expected from this change since (a) sloppy locking does not change the behavior of applications and (b) those applications that work with sloppy locking are a strict superset of those that work without. This is not an issue anybody's time should be wasted on.

I agree with Tom Jaegar.

Currently common Java GUI applications simply crash on Hardy.
For a newcomer this is equivalent to "Java does not work on Ubuntu", that sounds especially bad for an LTS distro.

The patch was in fact needed for libxcb.

If I understand the original Debian thread correctly, this arises when someone writes sloppy code, no? Sloppy code should be fixed, instead of allowing broken behavior in the libraries...IMHO. Still, the closed-source java annoys me in that only Sun can fix the problem.

Is a fix forthcoming in libxcb, or do we wait for broken packages (Java most notably) to be updated? If no fix is in the pipeline, what is the temporary workaround? Just export and run java apps from the CLI every time?

Found a workaround on the Gentoo forums and adapted it to Ubuntu's locations.

NOTE: Newcomers...do NOT run this command. If you don't understand exactly what is going on, NEVER run a command you find online.

locate libmawt.so | grep "/usr/lib/jvm/java-6.*/lib/i386/.*libmawt.so" | xargs sudo sed -i 's/XINERAMA/FAKEEXTN/g'

@drdabbles: It is sounds easier for me to use export instead of replacing a string in a binary file. You don't have to use export from the CLI every time. Just put it into your .bashrc or add the variable to /etc/environment.
I guess sloppy locking refers to some locking method, and not to sloppy code.

Also please note the status of this bug: "Fix Committed". Probably with the next update the workaround will be unnecessary.

drbabbles,

A better workaround is to add a line "LIBXCB_ALLOW_SLOPPY_LOCK=1" to /etc/environment.

Regarding, your first comment, we can have our cake and eat it too. Just because we don't gratuitously crash applications doesn't mean we can't fix the underlying problems. A lot of extensions were affected by this. This means that whenever someone wants to use an application that includes statically linked older extension libraries, there's a good chance that it's gonna crash. That's completely absurd considering that the application will almost certainly work just fine.

Fixing this issue is completely trivial and has probably been done already if the status of the bug is any indication.

This bug was fixed in the package libxcb - 1.1-1ubuntu1

---------------
libxcb (1.1-1ubuntu1) hardy; urgency=low

  * Add 100_sloppy_lock.diff, which reverses the locking logic, ie. sloppy
    locking is the default. To disable that, set the environment variable
    LIBXCB_DISABLE_SLOPPY_LOCK to any value. (LP: #87947)

 -- Timo Aaltonen <email address hidden> Tue, 11 Mar 2008 21:31:54 +0200

Josh and I just proposed a set of changes to XCB and Xlib/XCB which, among other things, should address all the outstanding assertion failures and synchronization problems that we know of. Could anyone experiencing this bug please build XCB and Xlib with the patches found at http://lists.freedesktop.org/archives/xcb/2008-March/003347.html and retest?

I am trying to install VP-UML for eclipse. I tried all proposed workarounds and none worked. tried the
export LIBXCB_ALLOW_SLOPPY_LOCK=1
same result.
tried sed command, but apparently the installer packs its own version of libmawt.so

Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb7403767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb74038b1]
#2 /usr/lib/libX11.so.6(_XReply+0xfd) [0x7ce511bd]
#3 /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.18251.dir/jre/lib/i386/xawt/libmawt.so [0x7cf31d7e]
#4 /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.18251.dir/jre/lib/i386/xawt/libmawt.so [0x7cf1bd47]
#5 /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.18251.dir/jre/lib/i386/xawt/libmawt.so [0x7cf1bec3]
#6 /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.18251.dir/jre/lib/i386/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x26) [0x7cf1c106]
#7 [0xb181b008]
#8 [0xb1814b6b]
#9 [0xb1814b6b]
#10 [0xb1

urgently need to solve this.. :) has anyone tried the upstream patches?

here on latest hardy x86_64 with installed libxcb1 (1.1-1ubuntu1) installed. i still get the following error when starting tomcat from within eclipse:

Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x7f8d779f497c]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x24) [0x7f8d779f4a84]
#2 /usr/lib/libX11.so.6(_XReply+0x10f) [0x7f8d7c359f4f]
#3 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so [0x7f8d7c870786]
#4 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so [0x7f8d7c8514eb]
#5 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so [0x7f8d7c8517bd]
#6 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x12) [0x7f8d7c851a32]
#7 [0x7f8dc18af878]
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x7f8d779f497c]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_lock+0x15) [0x7f8d779f4a15]
#2 /usr/lib/libX11.so.6 [0x7f8d7c359323]
#3 /usr/lib/libX11.so.6(XGetVisualInfo+0x2c) [0x7f8d7c35072c]
#4 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so [0x7f8d7c850885]
#5 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so [0x7f8d7c850ad9]
#6 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so [0x7f8d7c85185f]
#7 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x12) [0x7f8d7c851a32]
#8 [0x7f8dc18af878]

setting LIBXCB_ALLOW_SLOPPY_LOCK=1 did not fix the problem for me.

I can confirm that, running matlab on current Hardy, with libxcb1 (1.1-1ubuntu1) gives the following :
andrzej@andrzej-laptop:~$ /opt/matlab/bin/matlab
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb5aee767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb5aee8b1]
#2 /usr/lib/libX11.so.6(_XReply+0xfd) [0xb5e5a1bd]
#3 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/i386/xawt/libmawt.so [0xaff828ce]
#4 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/i386/xawt/libmawt.so [0xaff5f067]
#5 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/i386/xawt/libmawt.so [0xaff5f318]
#6 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/i386/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x2f) [0xaff5f61f]
#7 [0xb0cd7ecd]
#8 [0xb0cd0edd]
#9 [0xb0cd0edd]
#10 [0xb0cce249]
#11 /usr/lib/jvm/java-6-sun/jre//lib/i386/client/libjvm.so [0x621c40d]
#12 /usr/lib/jvm/java-6-sun/jre//lib/i386/client/libjvm.so [0x6310378]
#13 /usr/lib/jvm/java-6-sun/jre//lib/i386/client/libjvm.so [0x621c2a0]
#14 /usr/lib/jvm/java-6-sun/jre//lib/i386/client/libjvm.so(JVM_DoPrivileged+0x363) [0x6272153]
#15 /usr/lib/jvm/java-6-sun/jre//lib/i386/libjava.so(Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x3d) [0xb2d3896d]
#16 [0xb0cd7ecd]
#17 [0xb0cd0d77]
#18 [0xb0cce249]
#19 /usr/lib/jvm/java-6-sun/jre//lib/i386/client/libjvm.so [0x621c40d]
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb5aee767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_lock+0x2e) [0xb5aee81e]
#2 /usr/lib/libX11.so.6 [0xb5e59518]
#3 /usr/lib/libX11.so.6(XGetVisualInfo+0x26) [0xb5e500a6]
#4 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/i386/xawt/libmawt.so [0xaff5e319]
#5 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/i386/xawt/libmawt.so [0xaff5e565]
#6 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/i386/xawt/libmawt.so [0xaff5f3c9]
#7 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/i386/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x2f) [0xaff5f61f]
#8 [0xb0cd7ecd]
#9 [0xb0cd0edd]
#10 [0xb0cd0edd]
#11 [0xb0cce249]
#12 /usr/lib/jvm/java-6-sun/jre//lib/i386/client/libjvm.so [0x621c40d]
#13 /usr/lib/jvm/java-6-sun/jre//lib/i386/client/libjvm.so [0x6310378]
#14 /usr/lib/jvm/java-6-sun/jre//lib/i386/client/libjvm.so [0x621c2a0]
#15 /usr/lib/jvm/java-6-sun/jre//lib/i386/client/libjvm.so(JVM_DoPrivileged+0x363) [0x6272153]
#16 /usr/lib/jvm/java-6-sun/jre//lib/i386/libjava.so(Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x3d) [0xb2d3896d]
#17 [0xb0cd7ecd]
#18 [0xb0cd0d77]
#19 [0xb0cce249]

Like exactt wrote - exporting LIBXCB_ALLOW_SLOPPY_LOCK=1 doesn't change anything, probably because it's already on by default.
exporting LIBXCB_DISABLE_SLOPPY_LOCK=1 brings up the "old" error :

 /opt/matlab/bin/matlab
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb5a70767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb5a708b1]
#2 /usr/lib/libX11.so.6(_XReply+0xfd) [0xb5ddc1bd]
#3 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/i386/xawt/libmawt.so [0xb015f8ce]
#4 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/i386/xawt/libmawt.so [0xb013c067]
#5 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/i386/xawt/libmawt.so [0xb013c318]
...

The (first) error message is expected when LIBXCB_ALLOW_SLOPPY_LOCK=1 is enabled.

As long as your app isn't crashing, you can safely ignore the error, since your app doesn't mix xlib and xcb.

The long term solution should be "socket handoff," but I don't think that will hit hardy: http://lists.freedesktop.org/archives/xcb/2008-March/003347.html

Another Confirmation for Hardy (with up-to-date updates) & Report of NO effect of the workaround
I try to use oracle SQLDeveloper & JDeveloper (both developed in java)
When using "java-6-sun-1.6.0.06" It works kind of (but not fully because oracle only supports java 1.5)
But when using "java-1.5.0-sun-1.5.0.15" I get a whole bunch of errors, and the content of the window keeps missing:
<code>
Oracle JDeveloper 10g 10.1.3.3
Copyright 1997, 2007 Oracle. All Rights Reserved

Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb24b3767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb24b38b1]
#2 /usr/lib/libX11.so.6(_XReply+0xfd) [0x85f591bd]
#3 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/xawt/libmawt.so [0x861f8dce]
#4 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/xawt/libmawt.so [0x861e2d77]
#5 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/xawt/libmawt.so [0x861e2ef3]
#6 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x26) [0x861e3136]
#7 [0xb2540c1b]
#8 [0xb253ab3b]
#9 [0xb253ab3b]
#10 [0xb2538219]
#11 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/client/libjvm.so [0xb775c2bc]
#12 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/client/libjvm.so [0xb7870ed8]
#13 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/client/libjvm.so [0xb775c0ef]
#14 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/client/libjvm.so(JVM_DoPrivileged+0x32d) [0xb77b9b9d]
#15 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/libjava.so(Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x3d) [0xb755630d]
#16 [0xb25404bb]
#17 [0xb253aa64]
#18 [0xb2538219]
#19 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/client/libjvm.so [0xb775c2bc]
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb24b3767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_lock+0x2e) [0xb24b381e]
#2 /usr/lib/libX11.so.6 [0x85f58518]
#3 /usr/lib/libX11.so.6(XGetVisualInfo+0x26) [0x85f4f0a6]
#4 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/xawt/libmawt.so [0x861e20b9]
#5 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/xawt/libmawt.so [0x861e2303]
#6 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/xawt/libmawt.so [0x861e2fa1]
#7 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x26) [0x861e3136]
#8 [0xb2540c1b]
#9 [0xb253ab3b]
#10 [0xb253ab3b]
#11 [0xb2538219]
#12 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/client/libjvm.so [0xb775c2bc]
#13 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/client/libjvm.so [0xb7870ed8]
#14 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/client/libjvm.so [0xb775c0ef]
#15 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/client/libjvm.so(JVM_DoPrivileged+0x32d) [0xb77b9b9d]
#16 /usr/lib/jvm/java-1.5.0-sun-1.5.0.15/jre/lib/i386/libjava.so(Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x3d) [0xb755630d]
#17 [0xb25404bb]
#18 [0xb253aa64]
#19 [0xb2538219]
</code>

Please tell me how to correctly work around this bug, or how it can be fixed

Jamey, I would be more than willing to test the socket handoff patches, but I cannot get the patches to apply well. If I checkout current git and do git-apply --check --summary, only the first patch does not yield any problems. I suppose I need to check out a specific revision of libxcb? If you could give me a hint as to how I can find the right revision, I'll give it a shot.

Thanks for testing! The handoff patches are based on libxcb git commit 7a74ba3d0212f9bfe021d6da9070f71cbc53f85b and libX11 git commit 64325f38bab082a8e0e9ce779a8e582de5c8588e. It'll probably apply against newer versions of libX11, but there's been a lot of work in libxcb since we started trying to make this new handoff approach go, so I'm not surprised the patches don't apply.

Why was this declined for hardy between it and bug 185311 it is apparently causing lots of crashes on OpenOffice.org.

Thanks,

Chris Cheney

I still get issues when running MATLAB r2008 under Hard (32-bit and 64-bit). I've tried the sed thing, the SLOPPY_LOCK export and have all the updates installed as of today.

Basically, matlab over UNIX sockets (the default, DISPLAY=:0.0) seems fine, but over TCP sockets (DISPLAY=localhost:0) is is usably slow. Even older versions of matlab have issues. Same applies to Maple and any other odd Java programs I have. I need the TCP sockets because I'm deploying (well, stalled until this is sorted) Ubuntu on servers here which I need X11-over-TCP for.

Why can't we just remove the XCB infection/bridge layer from libX11 and revert it to the stock libX11 module? Let old libX11 programs use that, and new ones use XCB.

Thanks!

Sorry, I meant to say "unusably slow". TCP/X11 transport of Matlab and other Java applications are unusably slow even with all the hacks and updates applied.

I neither understand why this bug is declined for the Long Term Support "hardy" release....
Does that mean I have to update to an "intermediate" yet unreleased version ?

Thanks
Chris

"Why can't we just remove the XCB infection/bridge layer from libX11 and revert it to the stock libX11 module? Let old libX11 programs use that, and new ones use XCB."

Far as I understand the issue, it is because some apps (e. g. compiz) don't work without.
I think the ideal short term solution for hardy would be to provide both versions of libX11. Make the non-xcb version the default and make apps which need xcb depend on the xcb enabled version placed in a different directory, then compile them with a runtime linker path pointing to that alternative xcb-enabled library.
I have just tested Bryce's non-xcb libs by simply extracting the debs to a given directory, unsetting LIBXCB_ALLOW_SLOPPY_LOCK, setting LD_LIBRARY_PATH to the directory with the the non-xcb libX11 and starting an app I was previously having problems with on hardy but none on gutsy. And, of course, everything worked like a charm.

fixed in 6-07 in intrepid

charly4711: We can't provide both versions of libX11 because it would almost certainly result in two copies of libX11 (one with XCB and one without) sometimes being loaded into the one process depending on the exact transitive library linkage involved, which would cause chaos and crashes. We can't simply roll back to non-XCB libX11 since, as you say, compiz requires the XCB version.

I'm afraid that, much though we would like it to be otherwise, there is no quick and easy resolution to this bug (actually bug 185311, which is where we're really tracking it). It is a very important bug, and we're tracking it as a release-critical issue, but unfortunately that doesn't automatically translate into an easy fix ...

Hiya -

Just to confirm, the noxcb deb files above allowed python-pyxine to work properly on hardy, where previously it had suffered a hard lockup just after creating the display visual object and spawning the X event thread.

I would certainly like to have this module working on a long-term support release, but I understand the situation you're in. Thank you for your continuing efforts!

Of course, I realize I'm probably one of relatively few people using pyxine in favour of gstreamer ...

Sorry, I had meant to post the above on the end of #185311.

Colin, though I appreciate the complexity of the issue, I feel like we have "chaos and crashes" now! I, personally, also feel that if libxcb has those issues, that version should never have made it through QA and into an LTS release, and that I'd much rather have a statically linked compiz than encounter crashes or deadlocks in every other application that does mildly complex X11 stuff.