Red Hat Bugzilla – Bug 301691
Azureus and all java apps are crashing (xcb_xlib_unlock: Assertion)
Last modified: 2007-12-27 07:03:59 EST
Description of problem:
Azureus or others java graphical apps crash in the rawhide branch.
i "think" the problem is introduced from the usage of libxcb package and
reliking of xlibs against it...
azureus crash seem related to SWT library... others java apps (tryed IntelliJ
IDEA, JXplorer and Aqua Datastudio) crash with the following error:
java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Tried the following java versions (in order):
- Java SUN JDK/JRE 1.6u2
- Java SUN JDK/JRE 1.7.0-ea-b20
no java apps are working right now :-) (updated to rawhide 20070922)
Version-Release number of selected component (if applicable):
launch azureus or others java graphical apps
Steps to Reproduce:
i found some links reporting the above problem with a "workaround":
cp libmawt.so libmawt.so-orig
sed -i 's/XINERAMA/FAKEEXTN/g' libmawt.so
this seem solve the problems with java apps, but disable Xinerama support.
thanks - I had the same issue - resolved with workaround.
Moving this to libxcb, since openSUSE has a patch for it that we might want to
The bug also affects R's JGR GUI add-on.
The opensuse patch is not really something I'm comfortable with shipping. XCB
has locking assertions for a reason; if they're getting tripped, something is
More to the point is this analysis of the bug upstream:
The JDK you're using is broken. It's never been safe, it's just now it's
refusing to be unsafe.
Fortunately I think we can fix this in icedtea.
Created attachment 214941 [details]
This patch to the jdk should make us link against the system libXinerama, which
is always built threadsafe. In addition you'll need to add
to the specfile.
The same problem occurs with Matlab.
Matlab uses its own java libraries.
The patch fixes it, but you have to apply to the matlab version of the lib.
('locate libmawt.so' to find it).
Can we be sure to fix this for Fedora 8 please?
Created attachment 221391 [details]
error report file
Comment on attachment 221391 [details]
error report file
above patch does fix the startup problem. But if I select a file in Azureus and
use the right mouse click option "Show Details" Azureus crashes:
# An unexpected error has been detected by Java Runtime Environment:
# SIGSEGV (0xb) at pc=0xb5106e62, pid=3160, tid=3086154640
# Java VM: Java HotSpot(TM) Client VM (1.6.0_02-b05 mixed mode, sharing)
# Problematic frame:
# C [libgtkjni-2.8.so+0x7ae62]
# An error report file with more information is saved as hs_err_pid3160.log
# If you would like to submit a bug report, please visit:
/usr/bin/azureus: line 18: 3160 Aborted
jakarta-commons-cli log4j gtk2.8 glib0.2`:/usr/share/azureus/Azureus2.jar java
-Dazureus.install.path=$APPDIR org.gudy.azureus2.ui.swt.Main "$@"
*** Bug 254144 has been marked as a duplicate of this bug. ***
*** Bug 344591 has been marked as a duplicate of this bug. ***
*** Bug 357471 has been marked as a duplicate of this bug. ***
*** Bug 365911 has been marked as a duplicate of this bug. ***
Fixing it in icedtea is not an option for Java developers, etc, who need to have
multiple older JDK on their system.
Please remove the assertions at least temporarily.
(In reply to comment #16)
> Fixing it in icedtea is not an option for Java developers, etc, who need to have
> multiple older JDK on their system.
So much for write once, run anywhere.
> Please remove the assertions at least temporarily.
No. The asserts are there for a reason. They prevent race conditions that
would otherwise be maddening to debug. I'm not going to sacrifice guaranteed
correctness for heisenbugs.
If you need to work around this for an older JDK, refer to comment #1.
I understand that there are good reasons for the assert. Anyhow Java obviously
worked all the years before, even with the flaw.
As a professional Java developer, I know that it is sometimes difficult or even
impossible to apply the workaround mentioned in comment #1, especially if
customers are involved. Some software brings its own JVM, or is certified to run
only on a concrete Java version, so there is no way to use a Java update with
the bug fixed, or IcedTea as a replacement.
I propose that instead of the assert, a warning message is dumped, but the
function continues as it did before. This would keep the possibility to find
race conditions, and would still allow to use older Sun Java installations.
(In reply to comment #18)
> I understand that there are good reasons for the assert. Anyhow Java obviously
> worked all the years before, even with the flaw.
Worked until it didn't, sure.
> I propose that instead of the assert, a warning message is dumped, but the
> function continues as it did before. This would keep the possibility to find
> race conditions, and would still allow to use older Sun Java installations.
Install the appropriate rpm from:
And run the app with LIBXCB_ALLOW_SLOPPY_LOCK=1 in the environment.
The spec file for those rpm's defines but doesn't apply the patch ;)
May be worth pointing out that this is biting things other than Java, also
breaks the Citrix ICA client..
(In reply to comment #20)
> The spec file for those rpm's defines but doesn't apply the patch ;)
> May be worth pointing out that this is biting things other than Java, also
> breaks the Citrix ICA client..
I don't have that handy. I assume it's statically linked to something though?
It would be best to have a new bug for that issue.
FWIW, upstream libxcb 1.1 seems to have a similar LIBXCB_ALLOW_SLOPPY_LOCK
workaround included in non-NDEBUG builds.
*** Bug 383331 has been marked as a duplicate of this bug. ***
*** Bug 383821 has been marked as a duplicate of this bug. ***
*** Bug 370711 has been marked as a duplicate of this bug. ***
Some programs have their own JAVA installers that unpack from zips.(In reply to
> i found some links reporting the above problem with a "workaround":
> the workaround:
> cd $JAVA_HOME/lib/i386/xawt
> cp libmawt.so libmawt.so-orig
> sed -i 's/XINERAMA/FAKEEXTN/g' libmawt.so
> this seem solve the problems with java apps, but disable Xinerama support.
This cannot be applied always. Maple for example unpacks its own
Java/libmawt.so for installation. You would have to unpack Maple somehow, apply
patch, pack Maple, install.
What I did was to downgrade to libX220.127.116.11, install Maple, update libX11, and
patch the Maple libmawt.so.
*** Bug 387071 has been marked as a duplicate of this bug. ***
*** Bug 386321 has been marked as a duplicate of this bug. ***
I had The same bug. So I used the woraround. This worked probably and all my
java applications worked fine again.
Now, I wanted to update my BOINC-client form v5.8.2 to 5.10.2 but when I want to
start the boincmgr I get again this error. Workaournd dosn't work.
As far as I know BOINC is NOT written in Java, but in GKT1
After updating from Fedora 7 to Fedora 8 Pro Engineer Wildfire 3 fails:
pro: xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.
I will give the above rpms a try, but I have to say, that programs like Maple
and Matlab, stated above, or ProE, in my case, most likely wouldn't adopt this
"change". And those are the programs/companies, who are so kind to ship their
professional software for Linux, too.
I will please the developers to fix this bug in the upstream so, that those
programs can work as they did before.
*** Bug 381861 has been marked as a duplicate of this bug. ***
Sun (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373) mark this as
"Closed, fixed", saying "https://bugs.freedesktop.org/show_bug.cgi?id=11390 was
filed against this problem, and since XCB team has accepted it, I'm closing this
CR as not a java bug."
bugs.freedesktop.org says RESOLVED NOTOURBUG. "...I spoke with Tom Marble of Sun
about this at OSCON, and he and I both agreed that this bug lies with the JDK..."
Above says "No. The asserts are there for a reason. They prevent race
conditions that would otherwise be maddening to debug. I'm not going to
sacrifice guaranteed correctness for heisenbugs."
So it looks like it's no-one's bug and it won't get fixed. I've tried most of
the suggested patches so far and they haven't worked. Whatever works needs to
get into the core distro anyway. I guess I had better go back to FC7 and forget
about FC8 :-(.
libxcb-1.0-4.fc8 seems to have fixed this bug; I believe it can be closed.
How do you check if this is fixed?
I have libxcb-1.0-4.fc8 installed, but no Java applets are working with Firefox.
[ivo@sarmax ~]$ rpm -q firefox
[ivo@sarmax ~]$ rpm -qa|grep java