FS#8521 - Java apps don't work after todays X update

Attached to Project: Arch Linux
Opened by Andrzej Giniewicz (Giniu) - Monday, 05 November 2007, 20:42 GMT
Last edited by Jan de Groot (JGC) - Wednesday, 07 November 2007, 11:51 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Alexander Baldeck (kth5)
Architecture All
Severity High
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 11
Private No

Details

Quite some Java apps don't work, with different stack, but always end with:

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

this touch for example jedit, and jgr addon to R (probably other gui java apps also? exception for first occurs in awt library, don't know about swing based interfaces...)
This task depends upon

Closed by  Jan de Groot (JGC)
Wednesday, 07 November 2007, 11:51 GMT
Reason for closing:  Fixed
Comment by Attila (attila) - Monday, 05 November 2007, 21:12 GMT
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
Comment by Andrzej Giniewicz (Giniu) - Monday, 05 November 2007, 22:01 GMT
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 :)
Comment by Jan de Groot (JGC) - Monday, 05 November 2007, 23:41 GMT
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.
Comment by Joe Bates (jbizzler) - Tuesday, 06 November 2007, 01:53 GMT
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.
Comment by Jaideep Das (jaideep_jdof) - Tuesday, 06 November 2007, 09:22 GMT
Same problem with limewire and jacman.
Comment by Jordi Cerdan (jcerdan) - Tuesday, 06 November 2007, 09:57 GMT
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.
Comment by Jan de Groot (JGC) - Tuesday, 06 November 2007, 10:01 GMT
Please, stop adding these "me too" comments.
Comment by Dariusz Trzaska (saneone) - Tuesday, 06 November 2007, 12:53 GMT
What does "export LIBXCB_ALLOW_SLOPPY_LOCK=1" exactly do?

Doesn't it limit the JRE functionality somehow?
Comment by Jan de Groot (JGC) - Tuesday, 06 November 2007, 13:25 GMT
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.
Comment by Ustalov Dmitry (eveel) - Tuesday, 06 November 2007, 14:49 GMT
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
Comment by Vladimir Chizhov (JaGoTerr) - Tuesday, 06 November 2007, 14:55 GMT
Bullshit, russian works fine on both jdk 5.0 & 6.0. At least for me (8-bit locale).
Comment by Alexander Baldeck (kth5) - Tuesday, 06 November 2007, 15:02 GMT
Can't reproduce the problem, azureus works fine still for me. with jr3 6u3-1.
Comment by Ustalov Dmitry (eveel) - Tuesday, 06 November 2007, 15:11 GMT
> 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?
Comment by soma irot (somairotevoli) - Tuesday, 06 November 2007, 15:21 GMT
> 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
Comment by Ustalov Dmitry (eveel) - Tuesday, 06 November 2007, 15:51 GMT
> 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
Comment by Ionut Biru (wonder) - Tuesday, 06 November 2007, 15:57 GMT
what about netbeans? this is more important than azureus
Comment by Ustalov Dmitry (eveel) - Tuesday, 06 November 2007, 15:58 GMT
netbeans 5.5.1 works fine
Comment by Timm (gummibaerchen) - Tuesday, 06 November 2007, 16:07 GMT
No, netbeans doesn't start without the workaround.

And you get quite some backtrace when starting with LIBXCB_ALLOW_SLOPPY_LOCK=true.
Comment by Alexander Baldeck (kth5) - Tuesday, 06 November 2007, 16:07 GMT
try libx11 -6.
Comment by soma irot (somairotevoli) - Tuesday, 06 November 2007, 16:22 GMT
>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
Comment by Ustalov Dmitry (eveel) - Tuesday, 06 November 2007, 16:29 GMT
> Azureus only works w/ "export LIBXCB_ALLOW_SLOPPY_LOCK=1" workaround

yes, export LIBXCB_ALLOW_SLOPPY_LOCK=1 is defined (see my previous posts)
Comment by soma irot (somairotevoli) - Tuesday, 06 November 2007, 21:08 GMT
Fixed w/ libx11 update.
Comment by Julio Jiménez (jujibo) - Tuesday, 06 November 2007, 21:27 GMT
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.

Comment by Julio Jiménez (jujibo) - Wednesday, 07 November 2007, 08:50 GMT
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
Comment by Jan de Groot (JGC) - Wednesday, 07 November 2007, 09:15 GMT
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)
Comment by Attila (attila) - Wednesday, 07 November 2007, 10:33 GMT
@Jan Because i use my 2 java apps very seldom, i have one question: How can i use the jdk from IBM in arch?
Comment by Alexander Baldeck (kth5) - Wednesday, 07 November 2007, 10:48 GMT
@ 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.
Comment by Julio Jiménez (jujibo) - Wednesday, 07 November 2007, 11:36 GMT
@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.

Comment by Jan de Groot (JGC) - Wednesday, 07 November 2007, 11:51 GMT
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.

Loading...