第一篇文章，就轉(zhuǎn)我自己的吧。
這是我試圖在openSuSE10.3上跑NetBeans時出現(xiàn)的問題，很嚴(yán)重，因為XCB的問題，導(dǎo)致了SWING寫的程序無法運行……
From my BLOG on Lily：
Solved.
安裝openSUSE 10.3后出現(xiàn)的問題，花了幾天時間解決。
(其實也不能說是解決，因為問題出在XCB上)
BUG描述：
運行用Swing的APP時，會無法啟動，顯示類似于"Assertion `c->xlib.lock' failed."的
問題
如Zend Studio和NetBeans無法正常啟動，官方解釋這是由于使用了XCB而不是LibX的緣故
，關(guān)鍵就在于assert時，Lock問題。一種解決方案是回去使用libx，另一種則是去掉asse
rt時的檢查。
下面的解決方案可行，(試過。)
［轉(zhuǎn)］
=======================================
Here's one explaination:
Re: NB doesn't work in open suse 10.3 "Assertion `c->xlib.lock' failed."
Click to flag this post
by pujansrt Oct 11, 2007; 02:45pm :: Rate this Message: - Use ratings to moder
ate (?)
Reply | Reply to Author | View Threaded | Show Only this Message
This is the solution--> just add this to your Environment
export LIBXCB_ALLOW_SLOPPY_LOCK=1
========================================
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373
Bug ID: 6532373
Votes 24
Synopsis xcb_xlib.c:50: xcb_xlib_unlock: Assertion 'c->xlib.lock' failed.
Category java:classes_awt
Reported Against
Release Fixed 7(b22)
State Closed, fixed
Related Bugs
Submit Date 08-MAR-2007
Description
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 start
up. 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 somethin
g in the standard build environment, or perhaps related to the defines in Xlib
Wrapper.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
Work Around
N/A
Evaluation
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 XLockDisp
lay() 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 vers
ion of
Xinerama we use. We have updated it in 7.0 and so the problem must not be rep
roducible
with latest builds of jdk 7.
Since I can not check this (I have no environment for this :( It would be nic
e 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 loo
ks like the problem is not in the code but in the environment :( The test i
s very simple: it calls LockDisplay() and _XReply(), in usual situation it han
gs 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(). A
nd 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 u
sed 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 closin
g 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 static
ally
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 w
hy 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 work
around
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 mai
n
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 t
ests (test/java/awt/Multiscreen & test/closed/awt/Multiscreen)
[SQE]
Posted Date : 2007-10-01 09:19:55.0