FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-b105, mixed mode)

(also occurs with jdk1.7.0-b09 snapshot)

ADDITIONAL OS VERSION INFORMATION :
Linux kellyc-desktop 2.6.20-9-generic #2 SMP Sun Feb 25 22:59:06 UTC 2007 x86_64 GNU/Linux
Ubuntu Feisty 7.04

EXTRA RELEVANT SYSTEM CONFIGURATION :
libxcb1                                  1.0-1.1

A DESCRIPTION OF THE PROBLEM :
Starting up any java app that uses awt gives this error immediately upon startup. E.g. jconsole. See this forum post: http://forum.java.sun.com/thread.jspa?threadID=782829

The error is: xcb_xlib.c:50: xcb_xlib_unlock: Assertion 'c->xlib.lock' failed.

This occurs with the latest 1.7.0-b09 snapshot build. However if I build 1.7.0-b09 (svn trunk revision #70) from source on my machine, it works fine in both the regular binary and fastdebug binary, so this could be related to something in the standard build environment, or perhaps related to the defines in XlibWrapper.c that look related to locking and are only enabled on internal builds.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Install java on a ubuntu 7.04 (feisty) system with updates applied.
Try to run jconsole from a terminal.
The error occurs.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
jconsole window should open.
ACTUAL -
no window opens.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
xcb_xlib.c:50: xcb_xlib_unlock: Assertion 'c->xlib.lock' failed.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
downgrade xcb and xlib
Posted Date : 2007-03-08 12:24:41.0

N/A

This issue has been already discussed in different forums, for example:

http://lwjgl.org/forum/index.php/topic,2168.0.html

In a few words, the answer is: AWT is not supposed (yet) to be used with XCB, or at least this nobody checked this. Probably, we need to pay more attention to XCB support.
Posted Date : 2007-03-09 08:09:18.0

as far asI understand to trigger this problem we need to call either XLockDisplay() or
XUnlockDisplay.  I've grepped for these names in our code and found nothing :(
So, I suspect it is a bug in some library we use (like Xrandr).

It would be nice to get stack trace for triggered assertion to understand what does
trigger this.  (Hope submitter should be able to get it)
Posted Date : 2007-03-12 07:39:15.0

well, it looks like everyone believe that the cause of the problem is old version of
Xinerama we use.  We have updated it in 7.0 and so the problem must not be reproducible 
with latest builds of jdk 7.

Since I can not check this (I have no environment for this :(  It would be nice to get confirmation from the comunity.
Posted Date : 2007-06-04 08:53:46.0

I've developed the small test (attached) to demonstrate the problem and it looks like the problem is not in the code but in the environment  :(   The test is very simple: it calls LockDisplay() and _XReply(), in usual situation it hangs because there is no replies, but on in bad it throws the assertion.

Here is what you need to reproduce the problem:
you need to build the test on platform which doesn't have xcb and then run it on a platform with xcb.

My theory about why we have the problem is as follows:

the test uses X11 library for LockDisplay() and Xext library for _XReply().  And it looks like the direct calls to LockDisplay() are not intercepted by XCB and so XReply() triggers the assertion :(

So, I'd say that this is no a java bug, but some problem with the way XCB is used on a platform :(
Posted Date : 2007-06-26 13:51:01.0

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.
Posted Date : 2007-06-28 07:11:25.0

The XCB team has determined this is not their bug, since JDK is using a statically
linked, non-thread-safe copy of libXinerama.  See Comment #3 on
https://bugs.freedesktop.org/show_bug.cgi?id=11390
Posted Date : 2007-07-26 15:36:03.0

I can not say that I do like the decision XCB team made, but I do understand why they
choose it :/

Will see what we can do here.

I'm not sure if we can always rely on Xinerama installed on a platform :( need to evaluate
this.
Posted Date : 2007-07-26 16:13:52.0

it looks like the only way for us is to use dlopen to work with Xinerama.
Since it is 2D who works with this stuff, I'm reassigning the problem to them.
Posted Date : 2007-08-06 14:47:25.0

awt_GraphicsEnv.c has two code paths
One for Solaris which uses dlopen, the other for Linux which uses a JDK
internal copy of Xinerama.c.

So the code path we need is already there (the solaris one) - it more or less just needs
to be made the Linux code path too - but pointing at libXibnerama not libXext
and we can delete the libXinerma source.

The principle consequence is that Linux envts which do not support that
lib will no longer have a Xinerama aware JDK. Seems they may be on their
way put anyway.
Posted Date : 2007-08-06 15:20:10.0

While using the dynamic library is preferred, can't you also fix it by using a 
version of the static library built with the thread-safe flag (-DXTHREADS)?
Posted Date : 2007-08-06 15:27:56.0

We could try do build Xinerama.c with DXTHREADS but it would require
investigation to see if that was going to cause problems too.
Also the preference of Linux distributions (and Sun) is for dynamic linking so that
patches are more easily applied. Think of the static linking to date as a workaround
for the previous lack of dynamic linking as an option.
Posted Date : 2007-08-07 00:13:05.0

Requires installing the lib-x11 in the experimental repository.
I've recreated the behavior this way:

	I installed debian 4.0r1
	Changed the sources.list to use "sid" (for unstable)
	did apt-get dist-upgrade
	Those two steps is the standard way to get to "Debian Unstable"
	Installed the sun-java6 packages
	It still didn't crash
	Added to sources.list:  deb http://ftp.us.debian.org/debian/ experimental main
	This accesses the experimental repository
	Ran: apt-get update; apt-get install libxcb1 libxcb-xlib0
	Now jconsole crashes with the reported error message

Announcement of lib-x11 availability in experimental
http://lists.debian.org/debian-devel-announce/2006/11/msg00010.html

http://packages.debian.org/experimental/libs/libx11-6
Posted Date : 2007-08-22 21:51:15.0

Forum discussion on SDN
http://forum.java.sun.com/thread.jspa?threadID=782829

Gentoo, sun-java-5
http://bugs.gentoo.org/show_bug.cgi?id=156353
"Fix" was to disable the XCB Xlib

Gentoo, sun-java-6
http://bugs.gentoo.org/show_bug.cgi?id=181617

Gentoo, sun-java-5
http://bugs.gentoo.org/show_bug.cgi?id=181854

An article saying XCB Xlib will not be used for Ubuntu 7.10 (gutsy gibbon).
http://www.desktoplinux.com/news/NS4979518777.html
They cite delays by the XCB team in fixing some bugs.
Posted Date : 2007-08-22 21:52:26.0

[SQE]
The fix affects Solaris and Linux.  To verify it run all multiscreen-related tests (test/java/awt/Multiscreen & test/closed/awt/Multiscreen)
[SQE]
Posted Date : 2007-10-01 09:19:55.0

I've got the same behavoir on my debian box (sid + parts of experimental).
I was able to produce a trace with x11 libs:
(gdb) bt
#0  0xb7f327f2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0xb7dd6dc1 in raise () from /lib/i686/cmov/libc.so.6
#2  0xb7dd8638 in abort () from /lib/i686/cmov/libc.so.6
#3  0xb7dd04ac in __assert_fail () from /lib/i686/cmov/libc.so.6
#4  0xb518b770 in xcb_xlib_unlock () from /usr/lib/libxcb-xlib.so.0
#5  0xb51db390 in _XReply (dpy=0x828fa00, rep=0xb7d81a10, extra=0, discard=0)
    at ../../src/xcb_io.c:364
#6  0xb52e322e in XineramaQueryScreens ()
   from /usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so
#7  0xb52c1ed7 in xineramaInit ()
   from /usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so
#8  0xb52c2188 in awt_init_Display ()
   from /usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so
#9  0xb52c248f in Java_sun_awt_X11GraphicsEnvironment_initDisplay ()
   from /usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so
#10 0xb5cb74fe in ?? ()
#11 0x080588e8 in ?? ()
#12 0xb7d81bd8 in ?? ()
#13 0x00000000 in ?? ()

Hi.
We have this bug in our bugzilla as well.
I attached strace output for 
Java 1.4.2
Java 1.5.0
Java 1.6.0
there:
https://bugzilla.novell.com/show_bug.cgi?id=252510

Please let me know, if you need more info.
Regards,
Daniel

Is it possible to attache files here? I would attach those strace output files here ... I just don't want to make this totally unreadable ;)

See also Bugreport in X.Org Bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=9336

# 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

#6  0xb7e7b7bb in __assert_fail () from /lib/libc.so.6
#7  0xb1dc7742 in xcb_xlib_unlock () from /usr/lib/libxcb-xlib.so.0
#8  0xb1e11412 in _XReply () from /usr/lib/libX11.so.6
#9  0xb1f52c7e in getAwtLockFunctions () from /usr/lib/jvm/java-1.5.0-sun-1.5.0_update10/jre/lib/i386/xawt/libmawt.so
#10 0xb1f3cc87 in Java_sun_awt_X11GraphicsDevice_initIDs ()
   from /usr/lib/jvm/java-1.5.0-sun-1.5.0_update10/jre/lib/i386/xawt/libmawt.so
#11 0xb1f3ce03 in Java_sun_awt_X11GraphicsDevice_initIDs ()
   from /usr/lib/jvm/java-1.5.0-sun-1.5.0_update10/jre/lib/i386/xawt/libmawt.so
#12 0xb1f3d046 in Java_sun_awt_X11GraphicsEnvironment_initDisplay ()
   from /usr/lib/jvm/java-1.5.0-sun-1.5.0_update10/jre/lib/i386/xawt/libmawt.so

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.

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.

This is in the Debian bug database in two places:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402165
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414535

Regards,
Andrew McMillan.

One workaround is to compile xcb with -DNDEBUG in CFLAGS.

There is a recent proposal on the xcb list to make that the default if it is configured w/o --debug; I don’t know whether that will happen.

Pretty serious regression since xcb is coming into common usage.  Will Sun fix this bug any time soon?

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.

- Josh Triplett

It *is* a bug of java, XCB only checks some assertions that haven't been checked before. The bug in Java is basically, that it is linked statically against libXinerama - so bugs in that library cannot be fixed inside awt.

The assertion in XCB will not go away, because triggering it just means, that behavior in the multithreaded case was undefined with libX11 w/o XCB. It's rather possible, that the workaround will go away soon, in which case java would completely cease to function on modern Linux systems.

>the test uses X11 library for LockDisplay() and Xext library for _XReply(). And it looks like the direct calls to LockDisplay() are not intercepted by XCB and so XReply() triggers the assertion :
XReply() is an Xlib function and should not be implemented in Xext.
What I seem to gather from the analysis is that Java replaces some of the Xlib functions and thus - depending on the context - one or the other version gets called. Java should not link against libX11 or any subset thereof nor should it link against any system provided X libraries.
I'm therefore not convinced if 'notabug' is the right resolution of this problem.

I spoke with several colleagues on the fd.o and XCB side of this problem, and we managed to track down this problem with more detail.  As far as we can tell, the JDK statically links with a libXinerama built against Xlib without XTHREADS #defined.  This makes LockDisplay() compile to nothing.  However, the JDK dynamically links to the system Xlib, which normally does have XTHREADS on any modern system.  This never represented a supported configuration, even well before XCB; you cannot use an extension library that doesn't use XTHREADS with an Xlib that does use XTHREADS.   XCB just exposes the problem, because an XCB-based Xlib always uses XTHREADS, and it needs the LockDisplay and UnlockDisplay macros to call the locking hooks because it does additional XCB-related processing in those hooks; thus, it includes locking correctness assertions in lieu of failing mysteriously when a library fails to do proper locking.

I spoke with Tom Marble of Sun about this at OSCON, and he and I both agreed
that this bug lies with the JDK; it needs to either dynamically link to the
system libXinerama, or statically link a libXinerama that uses XTHREADS (to
*hopefully* match the system Xlib it dynamically links), or statically link an
Xlib without XTHREADS.  Xlib and extension libraries like libXinerama must
agree about XTHREADS.

I have resolved the XCB bug
<https://bugs.freedesktop.org/show_bug.cgi?id=11390> as NOTOURBUG.  Please
reopen this bug.  Tom Marble said he would look into fixing it in the JDK and
the OpenJDK.

- Josh Triplett <josh@freedesktop.org>

My fedora just started this behavior. Yesterday it was fine, then when I did the usual update of my fc8, it suddenly stopped working. None of my java programs run anymore. =(
rawhide fedora with java version "1.5.0_06"
When I downgraded the libX11 library, the problem went away.
[root@wiz ~]# ll /var/cache/yum/development/packages/libX11*
-rw-rw-r-- 1 root root  814407 2007-04-07 04:37 /var/cache/yum/development/packages/libX11-1.0.3-8.fc7.i386.rpm
-rw-rw-r-- 1 root root  820903 2007-08-22 08:03 /var/cache/yum/development/packages/libX11-1.1.2-2.fc8.i386.rpm
-rw-rw-r-- 1 root root  680039 2007-04-07 04:37 /var/cache/yum/development/packages/libX11-devel-1.0.3-8.fc7.i386.rpm
-rw-rw-r-- 1 root root 1109904 2007-08-22 08:03 /var/cache/yum/development/packages/libX11-devel-1.1.2-2.fc8.i386.rpm
rpm -Uhv --oldpackage /var/cache/yum/development/packages/libX11*-1.0.3-8.fc7.i386.rpm
Preparing...                ########################################### [100%]
   1:libX11                 ########################################### [ 50%]
   2:libX11-devel           ########################################### [100%]

yay, it works. Thanks for the pointers or I would never have sorted this out. I will report the bug at fedora if I can.

In response to a link in the evaluation: the desktoplinux article says nothing about XCB at all, so that statement in the evaluation seems inaccurate.

To the anonymous Fedora user: does the sed workaround a few comments back work for you?

I have the same problem with OpenSuSE 10.3. 
The sed-workaround works for me. 
Many thanks for it!

another anon fedora user here.
The sed trick worked for me.
But, first I did a find /usr -name 'libmawt*' to find all of them.
This probably helped keep me from giving up since my problem was with a linux install of matlab. It had its own java libraries in /usr/local/matlab/sys/.....

Anyway. Thanks.

Thanks to the poster with the sed trick. That worked for me (opensuse 10.3). The same version of java 1.6.0_03 ran without problems under Ubuntu 7.10.

http://www.netbeans.org/servlets/ReadMsg?list=nbusers&msgNo=98765

I tried the sed workaround on openSUSE 10.3 to the files in both the OS's JRE and Matlab's JRE, on an x84_64. The system JRE, Matlab and Matlab JRE are all 64 bit. The sed workaround didn't work. 

I still have to do export LIBXCB_ALLOW_SLOPPY_LOCK=1 and run Matlab from a terminal. :-(

The sed workaround does not work for me. Azureus and Firefox crash.

Where is the fixed 7b22? I can see only 7b21, which still has this problem. I can't wait to stop using windows to access my bank account, this is really really annoying.

I've just installed 7b22 and it still triggers the assertion.

I solved this problem in fedora 7 x86_64;
download this:
libX11-1.0.3-8.fc7.i386.rpm
libX11-1.0.3-8.fc7.x86_64.rpm
libX11-devel-1.0.3-8.fc7.x86_64.rpm

and execute this;

[root@localhost ~]$ r[root@localhost aioria]# rpm -Uvh --force libX11-1.0.3-8.fc7.i386.rpm
[root@localhost ~]$ rpm -Uvh --force libX11-1.0.3-8.fc7.x86_64.rpm
[root@localhost ~]$ rpm -Uvh --force libX11-devel-1.0.3-8.fc7.x86_64.rpm


and java apps run ok !!

suerte !!

I solved this problem in fedora 7 x86_64;
download this:
libX11-1.0.3-8.fc7.i386.rpm
libX11-1.0.3-8.fc7.x86_64.rpm
libX11-devel-1.0.3-8.fc7.x86_64.rpm

and execute this;

[root@localhost aioria]# rpm -Uvh --force libX11-1.0.3-8.fc7.i386.rpm
[root@localhost ~]$ rpm -Uvh --force libX11-1.0.3-8.fc7.x86_64.rpm
[root@localhost ~]$ rpm -Uvh --force libX11-devel-1.0.3-8.fc7.x86_64.rpm


and java apps run ok !!

Lucks !!

Issue occurred in Fedora 8 install with Java JRE 1.6.001 running Jin client for ICC.

Previously in Fedora 7, using same JRE, there were no issues.

I upgraded to JRE 1.6.003 to no avail. I attempted to use JRE included with distro, to no avail.

I implemented "sed" fix listed above and it worked. Just an FYI to Fedora 8 users who might stumble across same issue.

Is there a backport to JDK 1.6 for this?  I would really like to run IntelliJ IDEA and it won't run in 1.7.

This should be included in the JDK 6 update 4 as well.

Yes, I have the same problem, when starting netbeans on Fedora Core 8:

$ java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
/usr/local/netbeans-6.0beta1/bin/../platform7/lib/nbexec: line 406:  2814 Neúspěšně ukončen (SIGABRT)        "/usr/java/jdk1.6.0/bin/java" -Djdk.home="/usr/java/jdk1.6.0" -classpath "/usr/local/netbeans-6.0beta1/platform7/lib/boot.jar:/usr/local/netbeans-6.0beta1/platform7/lib/org-openide-modules.jar:/usr/local/netbeans-6.0beta1/platform7/lib/org-openide-util.jar:/usr/java/jdk1.6.0/lib/dt.jar:/usr/java/jdk1.6.0/lib/tools.jar" -Dnetbeans.dirs="/usr/local/netbeans-6.0beta1/nb6.0:/usr/local/netbeans-6.0beta1/ide8:/usr/local/netbeans-6.0beta1/java1:/usr/local/netbeans-6.0beta1/xml1:/usr/local/netbeans-6.0beta1/apisupport1:/usr/local/netbeans-6.0beta1/enterprise4:/usr/local/netbeans-6.0beta1/mobility8:/usr/local/netbeans-6.0beta1/profiler2:/usr/local/netbeans-6.0beta1/ruby1:/usr/local/netbeans-6.0beta1/visualweb1:/usr/local/netbeans-6.0beta1/soa1:/usr/local/netbeans-6.0beta1/identity1:/usr/local/netbeans-6.0beta1/uml4:/usr/local/netbeans-6.0beta1/harness:/usr/local/netbeans-6.0beta1/cnd1:" -Dnetbeans.home="/usr/local/netbeans-6.0beta1/platform7" '-Dnetbeans.importclass=org.netbeans.upgrade.AutoUpgrade' '-Dnetbeans.accept_license_class=org.netbeans.license.AcceptLicense' '-Xmx377m' '-Dcom.sun.aas.installRoot=/usr/local/glassfish-v2-b58g' '-client' '-Xms32m' '-XX:PermSize=32m' '-XX:MaxPermSize=200m' '-Dapple.laf.useScreenMenuBar=true' '-XX:+UseConcMarkSweepGC' '-XX:+CMSClassUnloadingEnabled' '-XX:+CMSPermGenSweepingEnabled' org.netbeans.Main --userdir "/home/xsonnek/.netbeans/6.0beta1" "--branding" "nb"

I do have the same problem on eclipse when trying to run a java program. Its really annoying... 

sed workaround worked for:
      Fedora 8 x86_64 (2.6.23.1-49.fc8)
      JDK 1.5.0 Update 13

In Fedora 8 - Found out that if you remove or comment out the fontpath line in xorg.conf, all is well.

I just installed Fedora Core 8, released less than a month ago. The problem is still there with JDK 1.6.0_03 (which ran fine on Fedora 6 and 7). I tried the sed fix
sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/jre/lib/i386/xawt/libmawt.so
but it didn't work. I looked for fontpath in xorg.conf (as suggested recently) but didn't see it there to comment out :-(. libxcb was installed from libxcb-1.0-3.fc8.i386.rpm

I also encountered this error using the Debian package for JVM version 1.6.0.03.

The suggestion to use "sed" to modify the binary helped to remove the bug on my system.

the "sed fix" worked for me on Fedora 8

I tried the sed fix time ago.  Though it worked, the graphics applications decreased their performance noticeably. 

This has not changed with recent mustang update 3. Now, instead of an error, there is a warning "libxcb: WARNING! Program tries to unlock a connection without having acquired"

I am working with an OpenSuse 10.3 completely updated and the performance decrease occurs with 1.5 and mustang.

I beg your pardon? FIXED? Hell no!

The sed workaround is extremely dirty and just a VERY temporary workaround. As is with any product, downgrading is NOT a fix, especially not if it's a downgrade of a dependency. Also, even if it would be fixen in java 1.7, a patch for 1.6 and 1.5 is STILL needed, since it will certainly take a lot of time before all applications have switched to java 1.7, if at all.
 I COMMAND sun to reopen this bug.

The sed - fix worked für JDK6 on amd_64 opensuse 10.2 system. Bug occured after updating Xorg 7.2 to Xorg 7.3 
libmawt.so is located at /usr/lib64/jvm/jre-1.6.0-sun/lib/amd64/xawt

I have the same problem on opensuse 10.3
I use jdk 1.6.004, the sed workaround didn't work for me
it just removes the error message and after that while netbeans is starting it crashes 

I wonder how sun closed this bug, they didn't provide any fix for it even on their latest jdk release
Should sun close the bug based on some users suggested solution which is not a real solution and don't work on all system
I hope sun reopen this bug and provide a real fix for it in 1.6.005 release

Comment on 15-NOV-2007  said "This should be included in the JDK 6 update 4 as well."

Unfortunately someone responsible for bugs being fixed ignored this one because this bug is NOT fixed in update 4 (for which people were waiting for long time):

[arekm@tarm ~/test]$ cat Hello.java
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);
  }
}
[arekm@tarm ~/test]$ javac Hello.java
[arekm@tarm ~/test]$ java Hello
Locking assertion failure.  Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb7f166dd]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x2b) [0xb7f16811]
#2 /usr/lib/libX11.so.6(_XReply+0xf8) [0xad389d03]
#3 /usr/lib/jvm/java-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0xad4918ce]
#4 /usr/lib/jvm/java-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0xad46e067]
#5 /usr/lib/jvm/java-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0xad46e318]
#6 /usr/lib/jvm/java-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x2f) [0xad46e61f]
#7 [0xb5ce9e9d]
#8 [0xb5ce2edd]
#9 [0xb5ce2edd]
#10 [0xb5ce0249]
#11 /usr/lib/jvm/java-sun-1.6.0.04/jre/lib/i386/client/libjvm.so [0x621c40d]
#12 /usr/lib/jvm/java-sun-1.6.0.04/jre/lib/i386/client/libjvm.so [0x6310378]
#13 /usr/lib/jvm/java-sun-1.6.0.04/jre/lib/i386/client/libjvm.so [0x621c2a0]
#14 /usr/lib/jvm/java-sun-1.6.0.04/jre/lib/i386/client/libjvm.so(JVM_DoPrivileged+0x363) [0x6272153]
#15 /usr/lib/jvm/java-sun-1.6.0.04/jre/lib/i386/libjava.so(Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x3d) [0xb7cea96d]
#16 [0xb5ce9e9d]
#17 [0xb5ce2d77]
#18 [0xb5ce0249]
#19 /usr/lib/jvm/java-sun-1.6.0.04/jre/lib/i386/client/libjvm.so [0x621c40d]
java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
zsh: abort      java Hello
[arekm@tarm ~/test]$ java -version
java version "1.6.0_04"
Java(TM) SE Runtime Environment (build 1.6.0_04-b12)
Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode)

There is a workaround: just give Shell-command
	export LIBXCB_ALLOW_SLOPPY_LOCK=1
before you start a java program.

I inserted that line in my shell scripts which call java programs, and it is working fine. I did it also for the NetBeans start procedure, with the same success. (I am using NetBeans 5.5.1).

I got it from the java wrapper which is included in Suse Linux 10.3.

Tried to get firefox with java running under openSuse 10.3 x86_64.
Finally trowing away all java x86_64 stuff and replacing with 32bit versions, this error message  remained.
Thanks to search knowledge base I found Mat.Engel's workaround.
Now it works.

sed works for me...
My configuration is:
Linux 2.6.23.1-42.fc8 #1 SMP i686

Thanks! sed works on JRE:
sed -i 's/XINERAMA/FAKEEXTN/g' /usr/java/jre1.6.0_05/lib/i386/xawt/libmawt.so 

My configuration is Fedora 8 (libxcb-1.0-3.fc8) on JRE 1.6.0_05

- Clara Yeung

Thanks!
sed also works with Fedora 8 64 bit and jre1.6.0_05 (x64)

cat /etc/redhat-release 
Fedora release 8 (Werewolf)

sh jre-6u5-linux-x64-rpm.bin 
rpm -ivh jre-6u5-linux-amd64.rpm
rpm -q -a | grep jre
jre-1.6.0_05-fcs

sed -i 's/XINERAMA/FAKEEXTN/g' /usr/java/jre1.6.0_05/lib/amd64/xawt/libmawt.so

Tora

While not a substitute for fixing the JRE locking bug caused by statically linking a non-XTHREADS libXinerama, 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.

- Josh Triplett

testa-xp:/java/netbeans-6.0.1/bin # ./netbeans 
java: xcb_xlib.c:52: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
./../platform7/lib/nbexec: line 440:  6336 Abortado                "/usr/java/latest/bin/java" -Djdk.home="/usr/java/latest" -classpath "/java/netbeans-6.0.1/platform7/lib/boot.jar:/java/netbeans-6.0.1/platform7/lib/org-openide-modules.jar:/java/netbeans-6.0.1/platform7/lib/org-openide-util.jar:/java/netbeans-6.0.1/platform7/lib/locale/boot_ja.jar:/java/netbeans-6.0.1/platform7/lib/locale/boot_pt_BR.jar:/java/netbeans-6.0.1/platform7/lib/locale/boot_zh_CN.jar:/java/netbeans-6.0.1/platform7/lib/locale/org-openide-modules_ja.jar:/java/netbeans-6.0.1/platform7/lib/locale/org-openide-modules_pt_BR.jar:/java/netbeans-6.0.1/platform7/lib/locale/org-openide-modules_zh_CN.jar:/java/netbeans-6.0.1/platform7/lib/locale/org-openide-util_ja.jar:/java/netbeans-6.0.1/platform7/lib/locale/org-openide-util_pt_BR.jar:/java/netbeans-6.0.1/platform7/lib/locale/org-openide-util_zh_CN.jar:/java/netbeans-6.0.1/platform7/lib/locale/swing-l10n_pt_BR.jar:/usr/java/latest/lib/dt.jar:/usr/java/latest/lib/tools.jar" -Dnetbeans.system_http_proxy="DIRECT" -Dnetbeans.system_http_non_proxy_hosts="" -Dnetbeans.dirs="/java/netbeans-6.0.1/nb6.0:/java/netbeans-6.0.1/ide8:/java/netbeans-6.0.1/java1:/java/netbeans-6.0.1/xml1:/java/netbeans-6.0.1/apisupport1:/java/netbeans-6.0.1/enterprise4:/java/netbeans-6.0.1/mobility8:/java/netbeans-6.0.1/profiler2:/java/netbeans-6.0.1/ruby1:/java/netbeans-6.0.1/visualweb1:/java/netbeans-6.0.1/soa1:/java/netbeans-6.0.1/identity1:/java/netbeans-6.0.1/uml4:/java/netbeans-6.0.1/harness:/java/netbeans-6.0.1/cnd1:" -Dnetbeans.home="/java/netbeans-6.0.1/platform7" '-Dnetbeans.importclass=org.netbeans.upgrade.AutoUpgrade' '-Dnetbeans.accept_license_class=org.netbeans.license.AcceptLicense' '-Xmx354m' '-Dcom.sun.aas.installRoot=/home/raydacosta/glassfish-v2ur1' '-client' '-Xss2m' '-Xms32m' '-XX:PermSize=32m' '-XX:MaxPermSize=200m' '-Xverify:none' '-Dapple.laf.useScreenMenuBar=true' org.netbeans.Main --userdir "/root/.netbeans/6.0" "--branding" "nb"

For me the downgrade of libX11 was the solution. Thanks.

OpenSUSE 10.2
Linux 2.6.23.12-default #2 SMP Sun Jan 13 21:42:45 WET 2008 i686 i686 i386 GNU/Linux

Hi I am usinf fedora 8 and I have downloaded the 2 updates from Fedora 8 Update Repository

1.http://download.fedora.redhat.com/pub/fedora/linux/updates/8/i386/libxcb-1.0-4.fc8.i386.rpm
2.http://download.fedora.redhat.com/pub/fedora/linux/updates/8/i386/libxcb-devel-1.0-4.fc8.i386.rpm

And the nebeans-6.0-linux.sh installer is working and I have installed jdk-6u3-linux-i586-rpm.bin befor installing Netbeans-6

Hi I am usinf fedora 8 and I have downloaded the 2 updates from Fedora 8 Update Repository

1.http://download.fedora.redhat.com/pub/fedora/linux/updates/8/i386/libxcb-1.0-4.fc8.i386.rpm
2.http://download.fedora.redhat.com/pub/fedora/linux/updates/8/i386/libxcb-devel-1.0-4.fc8.i386.rpm

And the nebeans-6.0-linux.sh installer is working and I have installed jdk-6u3-linux-i586-rpm.bin befor installing Netbeans-6

same problem today with fedora 8, issue is good after use 
yum install libxcb in terminal console.

Keimpe de Jong

Problem is still there with the latest JRE (Java SE 6 Update 10 Beta (Build 23)) on openSuSE 10.3

Kindof crucial for MatLab

The fix must be in JD 6u10 as well as in the latest JDK 7.0 builds, so it looks strange to face the assertion again. Could you provide a stack trace (using gdb, for example) when the assertion is triggered?

I have installed JRE1.5.0_12 on Fedora 8. 
When I type javaws from terminal it returns 'java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed' error. 

I followed the sed - workaround but still no luck.I dont have java-1.5.0-sun-1.5.0.11or any such folder under jvm directory. Folders i have are java-1.5.0-gcj-1.5.0.0
java-1.7.0-icedtea-1.7.0.0
jre
jre-1.5.0
jre-1.5.0-gcj
jre-1.7.0
jre-1.7.0-icedata
jre-gcj
jre-icedata

and the sed command i used is

sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/jvm/jjre/lib/i386/xawt/libmawt.so
But still no luck. Anyone else who had the same problem and was able to solve it.?

Thanks,
Arpit
jain.arpit23@gmail.com