Seems to be a bug in Java:

see also:
http://people.debian.org/~terpstra/message/20061127.041128.8a08d75f.en.html
http://forum.java.sun.com/thread.jspa?threadID=782829&tstart=135


http://lists.freedesktop.org/archives/xcb/2006-November/002277.html
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
        https://bugs.freedesktop.org/show_bug.cgi?id=8521
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:
        https://bugs.freedesktop.org/show_bug.cgi?id=8582

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

--Jamey

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?

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.

        Bart

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

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.

        Bart

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.

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

What about applying the patch mentioned in

  https://bugzilla.novell.com/show_bug.cgi?id=251087

to have a workaround (environment variable) for applications/libs, which cannot be fixed, because they are closed source?

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);
    //setVisible(true);
  }
}
EOF
# javac Hello.java
# java Hello
java: xcb_xlib.c:52: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted
#

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

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.
Thanks.

You can file bugs against Sun Java at http://bugs.sun.com/

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.

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.

Looks like this has already been committed.

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

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.

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

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-1.5.0.11/jre/lib/i386/xawt/libmawt.so

For sun-java6-bin:
sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so

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

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.

*** Bug 13026 has been marked as a duplicate of this bug. ***

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?

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.

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.