Arch Linux

Thanks Andrzej for the warning because i start this java apps very seldom. Here is the same with JDictionary and TV Browser: java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

A message in a german forum (http://www.easylinux.de/pipermail/suse/2007-August/024996.html) said that this is a bug in Java 1.5 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373).

The workaround from the forum works here for me (instead of it works please make a backup of the file before):
sed -i 's/XINERAMA/FAKEEXTN/g' /opt/java/jre/lib/i386/xawt/libmawt.so

to add more... most apps stack trace start with:

Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb7f90767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb7f908b1]
#2 /usr/lib/libX11.so.6(_XReply+0xfd) [0xab7c7a8d]
#3 /opt/java/jre/lib/i386/xawt/libmawt.so [0xab8d264e]

it even hurts some web applets for me... wasn't trying above workaround yet, as I don't have good feeling about sed'ing in so files :)

Add "export LIBXCB_ALLOW_SLOPPY_LOCK=1" to /etc/profile.d/xorg.sh and you should be fine.

I would suggest either making this a default exported variable for now, or patching libxcb to do this by default. The previous version of libxcb in our repositories had patches to disable this behaviour.

Same problem here:
Assertion `c->xlib.lock' failed
I can't run Azureus or TopCoder Arena. Don't have any other Java apps, but they used to work before today's update.

Same problem with limewire and jacman.

Zend Studio stopped working too...here is the backtrace, maybe it helps.

Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb136c767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb136c8b1]
#2 /usr/lib/libX11.so.6(_XReply+0xfd) [0xb13b3a8d]
#3 /usr/local/Zend/ZendStudio-5.5.0/jre/lib/i386/xawt/libmawt.so [0xb14b6a76]
#4 /usr/local/Zend/ZendStudio-5.5.0/jre/lib/i386/xawt/libmawt.so [0xb149c80a]
#5 /usr/local/Zend/ZendStudio-5.5.0/jre/lib/i386/xawt/libmawt.so [0xb149ca51]
#6 /usr/local/Zend/ZendStudio-5.5.0/jre/lib/i386/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x24) [0xb149cc5c]
#7 [0xb2b13b6a]
#8 [0xb2b0da7b]
#9 [0xb2b0da7b]
#10 [0xb2b0b157]
#11 /usr/local/Zend/ZendStudio-5.5.0/jre/lib/i386/client/libjvm.so [0xb780bfec]
#12 /usr/local/Zend/ZendStudio-5.5.0/jre/lib/i386/client/libjvm.so [0xb79191f8]
#13 /usr/local/Zend/ZendStudio-5.5.0/jre/lib/i386/client/libjvm.so [0xb780be1f]
#14 /usr/local/Zend/ZendStudio-5.5.0/jre/lib/i386/client/libjvm.so(JVM_DoPrivileged+0x32d) [0xb78694bd]
#15 /usr/local/Zend/ZendStudio-5.5.0/jre/lib/i386/libjava.so(Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x3d) [0xb76252cd]
#16 [0xb2b1341b]
#17 [0xb2b0d9a4]
#18 [0xb2b0b157]
#19 /usr/local/Zend/ZendStudio-5.5.0/jre/lib/i386/client/libjvm.so [0xb780bfec]
java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

Please, stop adding these "me too" comments.

What does "export LIBXCB_ALLOW_SLOPPY_LOCK=1" exactly do?

Doesn't it limit the JRE functionality somehow?

Without the variable set libxcb abort()s your application because of the invalid lock. I'd like to reverse the behavior in libxcb to only abort when LIBXCB_ALLOW_SLOPPY_LOCK is set to 0 explicitly.

defining the LIBXCB_ALLOW_SLOPPY_LOCK=1 brokes the russian (and maybe other non-english) language on Java AWT (and Swing) applications
certainly, LIBXCB_ALLOW_SLOPPY_LOCK=1 slowdowns interaction of Java & X.org

I think, that this bug is _critical_. I can't work without jEdit

Bullshit, russian works fine on both jdk 5.0 & 6.0. At least for me (8-bit locale).

Can't reproduce the problem, azureus works fine still for me. with jr3 6u3-1.

> Can't reproduce the problem, azureus works fine still for me. with jr3 6u3-1.

azureus uses SWT, which works fine in current situation

> Bullshit, russian works fine on both jdk 5.0 & 6.0. At least for me (8-bit locale).

which applications you are using?

> azureus uses SWT, which works fine in current situation

NO it does not work fine in current situation. Same "java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." error

> NO it does not work fine in current situation. Same "java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." error

and azureus can't start? azureus works for me, but he prints the stack trace to the terminal

what about netbeans? this is more important than azureus

netbeans 5.5.1 works fine

No, netbeans doesn't start without the workaround.

And you get quite some backtrace when starting with LIBXCB_ALLOW_SLOPPY_LOCK=true.

try libx11 -6.

>and azureus can't start? azureus works for me, but he prints the stack trace to the terminal
Azureus only works w/ "export LIBXCB_ALLOW_SLOPPY_LOCK=1" workaround

> Azureus only works w/ "export LIBXCB_ALLOW_SLOPPY_LOCK=1" workaround

yes, export LIBXCB_ALLOW_SLOPPY_LOCK=1 is defined (see my previous posts)

Fixed w/ libx11 update.

It's a Java problem:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373

How to fix it:

sed -i 's/XINERAMA/FAKEEXTN/g' /opt/java/jre/lib/i386/xawt/libmawt.so


I hope it helps you.

The bug is not really fixed, I still get back trace everytime I run a java program using swing/awt. As I said in my post, is not an Archlinux bug, it's a java bug due the statically linked libxinerama. With the fix I proposed it works fine, no back trace, no need to use LIBXCB_ALLOW_SLOPPY_LOCK=1 with your fix, you are simply hidding the problem.
The real fix is to patch libmawt.so

thanks

Julio Jiménez

The sed hack is not the correct solution. It's clearly raping a closed binary with something it wasn't intended to do.
Live with the backtraces until sun decides to compile their java in a correct way or use a different JDK that is compiled in a way that is correct (IBM, gcj)

@Jan Because i use my 2 java apps very seldom, i have one question: How can i use the jdk from IBM in arch?

@ Julio
We are not hiding the problem. It is completely intentional to have those backtrace to hint at *BROKEN* applications instead of making them abort operation. If you don't like that, go and fix awt but we won't as we can only wait for yet another binary blob. Besides, this is another bug as it's not related to fixes in X.org packages.

@Jan de Groot, I don't need to live with those backtraces, I know why it happens, and the better fix (from my point of view) until sun fixes it in java 6 (it's fixed in java 7) it to attack the problem (libxinerama) patching the binary. I know this is a hack, but I guess this is better than having lots of backtraces everytime your java programs use awt/swing. For the moment using IBM or GCJ VMs is not a solution for me. I hope java will be fully Open Source soon and then these problems will be gone.

@Alexander Baldeck, why to have backtraces if you can fix it?. I don't like your fix, that's why I used the sed hack. About go and fix awt.. are you kidding? you know it's closed source I did the only fix I can. Of course is not a but related to X.org, it's a java bug and it's well documented in the link I gave you in my post.

Now Archlinux users can decide, to live with backtraces (just updating) or to live without it (using sed hack). I guess we can't do anymore until Sun fixes it. I used the second option.

Regular users don't even see the backtrace. We won't patch binaries with evil sed hacks. These apps run fine, though they print assertion backtraces everytime this bug in java is triggered. These assertion backtraces are harmless for normal use. If you don't want them, patch your own installation of java, but we won't do it.