Bug 9336 - Assert in each graphical Java application running SUN/IBM/BEA Java
Summary: Assert in each graphical Java application running SUN/IBM/BEA Java
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/Xlib (show other bugs)
Version: 7.2 (2007.02)
Hardware: Other Linux (All)
: high normal
Assignee: Jamey Sharp
QA Contact: Xorg Project Team
: 13026 (view as bug list)
Depends on:
Reported: 2006-12-13 13:53 UTC by Stefan Dirsch
Modified: 2008-11-22 14:26 UTC (History)
9 users (show)

See Also:
i915 platform:
i915 features:


Description Stefan Dirsch 2006-12-13 13:53:01 UTC
WW2D 0.99.88 by Vitaliy Pronkin <pronvit@gmail.com> starting...
TinyLaF v1.3.04
'Default.theme' not found - using YQ default theme.
java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
/opt/WW2D/ww2d: line 2: 14921 Aborted 
-Djava.library.path=./lib -Dopengl.1thread=false -Xmx512m -Xbatch -jar 
WW2D.jar $*

This is libX11 of X.Org 7.2 RC3 linked against libxcb 1.0 on an openSUSE 10.2 
system. ww2d is available at http://ww2d.org/home.php.
Comment 1 Stefan Dirsch 2006-12-13 15:46:27 UTC
Seems to be a bug in Java:

see also:

On Tue, Nov 07, 2006 at 11:53:03AM -0800, noidee wrote:
> After i have update from X11R6.9 to X11R7.1 and some applications
> crash  ( matlab , cedega and others)
> MATLAB: xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.
> or
> python: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
> /usr/bin/cedega: line 51: 30495 Aborted                 
${P2PPATH}/bin/python ${P2PPATH}/Point2Play_gui.py "$@"
> Is there anyone who know why ?
> I have Slackware 11.0 xorg 7.1 ( build from git ), mesa 6.5.1, cedega
> 5.1, matlab 7

Yes, we know generally what these errors mean: there's a bug in some
library or application that's using Xlib. Matlab is trying to lock the
Display structure twice; Cedega is trying to unlock it twice.

The Cedega bug is probably in Mesa: it looks like the 6.5.1 release
didn't get the fix from
The fix is in CVS; I don't know if there's a newer release that has the
fix too.

I can't tell exactly where the Matlab bug is without a stack trace from
gdb. But if you're using XIM, then it's probably this one:

If you can provide stack traces, we can provide more help.

Comment 2 Jamey Sharp 2006-12-18 02:06:50 UTC
I first thought this was a duplicate of bug #8926, but that should already be
fixed in libX11 from X.org 7.2 RC3.

Can you provide a stack trace, preferably with debugging symbols, from the point
when ww2d aborts?
Comment 3 Stefan Dirsch 2007-02-15 00:52:35 UTC
To: Hanno Böck <ml@hboeck.de>
Date: Wed, 14 Feb 2007 23:47:59 -0800
From: Barton C Massey <bart@cs.pdx.edu>
Cc: xorg@freedesktop.org
Subject: Re: java and xcb

IIRC we've seen this before, but I don't remember what the
resolution was.  Please file a bug report at
bugs.freedesktop.org, and be sure to note the versions of
things (in particular, java) that you're using so we can try
to reproduce.  Now that Sun's Java is open source, we have
at least a chance of fixing the likely root cause---locking
errors in the Java libraries.


In message <200702150308.24997.ml@hboeck.de> you wrote:
> Trying to run something in java with xcb on seems to fail:
> hanno@laverne ~/Desktop $ java -jar josm-latest.jar
> java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
> Abgebrochen
> Known issue?
> =2D-=20
> Hanno B=C3=B6ck               Blog:   http://www.hboeck.de/
> GPG: 3DBD3B20         Jabber: jabber@hboeck.de
Comment 4 Stefan Dirsch 2007-02-15 00:53:49 UTC
To: Arkadiusz Miskiewicz <arekm@maven.pl>
Date: Thu, 15 Feb 2007 00:05:51 -0800
From: Barton C Massey <bart@cs.pdx.edu>
Cc: xorg@lists.freedesktop.org
Subject: Re: java and xcb

Thanks much for the note.  This patch will stop java from
failing these asserts.  However, the general consensus among
X development leaders has been that we want to fix the
callers of Xlib with locking bugs rather than partially
papering them over.

Typically, if you are seeing one of these assertions trigger
it means that code is not properly acquiring or releasing an
Xlib lock.  Since such code is almost invariably
multithreaded (else why would it mess with Xlib locking in
the first place) it is probably going to experience other,
harder to diagnose, misbehaviors or failures.

If we can identify the offending calling code, I'm confident
we can get it fixed properly with little effort.


In message <200702150851.41417.arekm@maven.pl> you wrote:
> On Thursday 15 of February 2007, Barton C Massey wrote:
> > IIRC we've seen this before, but I don't remember what the
> > resolution was. 
> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/libxcb-no-assert-on-lock.patch?rev=1.1
> from ArkLinux afaik.
Comment 5 Daniel Stone 2007-02-27 01:35:04 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 6 Stefan Dirsch 2007-03-04 02:05:55 UTC
What about applying the patch mentioned in


to have a workaround (environment variable) for applications/libs, which cannot be fixed, because they are closed source?
Comment 7 Stefan Dirsch 2007-03-12 11:48:46 UTC
Simple example for reproduction.

# cat > Hello.java << EOF
import java.awt.*;

public class Hello extends Frame {
  public static void main(String argv[])
    new Hello();
  Hello() {
    Label hello = new Label("Hello World");
    //add(hello, "Center");
    //setSize(200, 200);
# javac Hello.java
# java Hello
java: xcb_xlib.c:52: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

I tried several Java implementations. Results:
SUN Java 1.6.0       broken (xcb assertion above)
IBM Java 1.5.0       broken (xcb assertion above)
bea Java 1.4.2       broken (xcb assertion above)
cacao Java 1.4.2     works
gcj Java 1.4.2       works
Comment 8 Stefan Dirsch 2007-03-19 03:25:23 UTC
I've added a few SUN developers. I hope that it would be possible to find a contact to the Java developers this way ?!? So any help would be appreciated.
Comment 9 Alan Coopersmith 2007-03-19 08:45:52 UTC
You can file bugs against Sun Java at http://bugs.sun.com/
Comment 10 Stefan Dirsch 2007-03-19 09:32:10 UTC
I'm afraid such a bugreport will be ignored without having any contacts beforehand to the Java SUN developers. I did hope it would be easier, if such a request/bugreport would have been openened by a SUN developer.
Comment 11 Alan Coopersmith 2007-03-19 09:50:46 UTC
Not really - the last bug I sent to the Java developers was closed with
"This is nonsense", so they don't have extra special love for us.
Comment 12 Stefan Dirsch 2007-03-19 11:34:42 UTC
Looks like this has already been committed.

Comment 13 Stefan Dirsch 2007-03-28 13:33:46 UTC
Some comments from SUN Bugzilla:

  Submitted On 20-MAR-2007 (Egbert Eich)
It looks like SUN is using a statically linked version of libXinerama in its java.
Doing a:
LD_PRELOAD=~/xorg/install/lib/libXinerama.so.1.0.0 DISPLAY=:0 java Hello
with a version of the libXinerama from X.Org works around the issue. This lib can be stripped down this function to XineramaQueryScreens().
This function however has received one single fix by Alan Coopersmith of SUN since it has been incorporated into the XFree86 tree. This fix however is entirely unrelated to this problem.
This indicates that SUN is using a copy of the libXinerama in java which predates the version that was incorporated in XFree86 in 2000. It's possible that the version comes from old X.Org's SI.

  Submitted On 28-MAR-2007 
Stefan Dirsch <sndirsch@suse.de>
I figured out that 
LD_PRELOAD=~/xorg/install/lib/libXinerama.so.1.0.0 DISPLAY=:0 java Hello
only works with SUN Java 1.4.2, but doesn't help when using SUN Java 1.5.0 or SUN Java 1.6.0. You still get the xcb assertion with newer SUN Java versions than 1.4.2.
Comment 14 Stefan Dirsch 2007-03-28 13:34:32 UTC
I did some more testing with LD_PRELOAD=/usr/lib/libXinerama.so.1:

            SUN         IBM      BEA
1.4.2      works       works    works
1.5.0      xcb ass.    works     N/A
1.6.0      xcb ass.     N/A      N/A
Comment 15 Josh Triplett 2007-06-02 19:03:17 UTC
I worked with jcristau and christoph4 via IRC on #debian-x, and we managed to
track down the problem with broken locking in Sun Java 1.5 and 1.6.  It only
occurs if Java finds the Xinerama extension, at which point it does something
broken with locking and triggers the assertion.  If Java never finds the
Xinerama extension, it doesn't trigger the assertion for broken locking.

The following workarounds address this problem:

For sun-java5-bin:
sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/jvm/java-1.5.0-sun-

For sun-java6-bin:
sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/jvm/java-6-sun-

The same fix (applied to the appropriate file) might work for other
proprietary JDKs.
Comment 16 Hanno Böck 2007-08-28 05:44:13 UTC
Any progress from the sun-people? Last info was that a sun-dev recognized the bug, but nothing happened since then. I've tried out with latest openjdk/sun-jdk-beta versions and the bug is still there.

We recently had a discussion at gentoo about the xcb-switch (and as compiz and other apps are adding xcb-only functionality it's probably time for that), where several people noted that java is the main blocker for that.
Comment 17 Ian Osgood 2007-10-31 10:55:25 UTC
*** Bug 13026 has been marked as a duplicate of this bug. ***
Comment 18 Josh Triplett 2007-11-04 10:43:22 UTC
OpenJDK beta 22 should fix this issue.  It dlopens libXinerama, rather than statically linking in the source of Xinerama without #define XTHREADS.

For anyone experiencing this problem: can you please check with OpenJDK beta 22?
Comment 19 Josh Triplett 2008-03-15 22:29:44 UTC
While the locking bug in Java remains, Jamey and I recently announced a change to Xlib/XCB and XCB which should, among other things, address this problem.  Our change introduces a new handoff mechanism in XCB, and uses that mechanism in Xlib/XCB.  The new mechanism no longer relies on hooking LockDisplay and UnlockDisplay, and thus no longer cares any more than Xlib does about whether Xlib callers use correct locking.  Thus, our change removes the infamous locking assertions.  Anyone experiencing this problem should try building XCB and Xlib/XCB with the patches from http://lists.freedesktop.org/archives/xcb/2008-March/003347.html and retesting.
Comment 20 Stefan Dirsch 2008-11-22 14:26:20 UTC
I think everybody gave up on this a long time ago and applies some 'always sloppy' patch to libxcb. SUSE/Novell does this now since April 2007.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.