Bug 254144

Summary: java Assertion `c->xlib.lock' failed
Product: [Fedora] Fedora Reporter: HughieB <nojunk311>
Component: libX11Assignee: Søren Sandmann Pedersen <sandmann>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: medium    
Version: rawhideCC: darrellpf, dhaval.giani, erik-fedora, eteo, horsley1953, kem, k.georgiou, mcepl, me, rkhadgar, sangu.fedora, stuart.i.campbell, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-18 17:41:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
backtrace file none

Description HughieB 2007-08-24 13:39:04 UTC
Description of problem:
Java X11 fails with the latest libX11 fc8 rawhide

Version-Release number of selected component (if applicable):
libX11-1.1.2-2.fc8.i386.rpm
libX11-devel-1.1.2-2.fc8.i386.rpm
java version "1.5.0_06"
How reproducible:
Install and run java application that uses X11
I was using MrPostman, but all my browsers crash when I go to a site that uses 
the java plugin too.
  
Actual results:
java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

Expected results:
I should work. I did until this upgrade

Additional info:
Once I downgraded back to the fc7 versions it worked fine:
libX11-1.0.3-8.fc7.i386.rpm
libX11-devel-1.0.3-8.fc7.i386.rpm

I reported this @ Sun because they seem to be having this problem with X11 of 
Linux a lot:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373

Comment 1 darrell pfeifer 2007-09-02 15:47:37 UTC
Installed IcedTea. Tried a few Java Swing/AWT applications. They work without
the lock problem.

Comment 2 HughieB 2007-09-03 14:08:42 UTC
I don't know ice tea. I don't think it has to do with swing anyway. Mr postman 
is a java application that browses web to pop your hotmail, yahoo etc. It run's 
as a daemon in the background but can have a tk interface I think. Anyway. It's 
the browser that crashes as soon as it tries to load an applet. I tried a few. 
My favorite is runescape. I have upgraded to java 6 and I still have the same 
problem. There seems to be a dependency. Check the sun bug id. The old version 
of libX11 works fine.

Comment 3 darrell pfeifer 2007-09-03 14:18:10 UTC
IcedTea is Fedora's implementation of Sun's OpenJDK (that is, Sun open sourced Java)

If you install it you will have a workaround to run your Java programs.

It also points out that there is an version of Java that is very close to the
Sun one which doesn't have the lock problem. Note that Sun's alpha/beta snapshot
Java 7's do have the lock problem.

Comment 4 Dennis Jacobfeuerborn 2007-09-04 01:29:44 UTC
Downgrading to libX11-1.0.3 "fixes" this issue as well:
http://koji.fedoraproject.org/koji/buildinfo?buildID=1730

Comment 5 sangu 2007-09-10 08:13:32 UTC
Created attachment 191471 [details]
backtrace file

Using XIM in emacs unicode-2 branch.
$emacs 
emacs: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

Comment 6 Gary Yuen 2007-09-11 10:58:55 UTC
Same xlib error trying to vmware-user that's part of VMware Tools. 

Comment 7 Matěj Cepl 2007-09-11 23:59:54 UTC
If this is not a problem with IcedTea (GPL-covered version of Sun Java) which
will be default Java on F8 anyway, then it is most probably WONTFIX.

Reporter, could you remove Sun binary-only Java 1.6* you have from Sun's website
(save it somewhere, you will need it -- IcedTea is not yet production-ready) and run

yum install java-1.7.0-icedtea-{plugin,demo,}

Then try to reproduce the bug. Did anything changed?


Comment 8 sangu 2007-09-25 15:52:41 UTC
Fixed  comment #5 in libX11 1.1.3-1.fc8.


Comment 9 HughieB 2007-10-05 17:01:45 UTC
I've finally been able to test this with the latest version I have libX11-1.1.3-
1.fc8.i386.rpm but it has the same problem. My java plugin crashes in my 
browser.

Comment 10 Matěj Cepl 2007-10-18 11:36:18 UTC
Reporter, which java it is (i.e., what is the output of java -version on your
computer)?

Comment 11 HughieB 2007-10-18 12:01:55 UTC
As I said in the initial report java version "1.5.0_06" and in comment #2, I 
upgraded to java 6
[hugh@wiz ~]$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode)
I hope someone can fix this there are comments at sun about this issue being 
upstream. It seems to be a dependency on something provided in /usr/lib/
libX11.so.6. XCB libXinerama. java is apparently linked statically against it? 
I don't know.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373
http://www.netbeans.org/servlets/ReadMsg?list=nbusers&msgNo=98765
The same error is reported in SUSE 10.3, gentoo, debian
Perhaps we can crack this one?


Comment 12 Adam Jackson 2007-10-18 17:41:55 UTC
This is already fixed in icedtea; we can't fix it in the other JDKs, and it's
not a bug in libxcb.

*** This bug has been marked as a duplicate of 301691 ***

Comment 13 HughieB 2007-10-20 07:51:24 UTC
Why doesn't icetea set itself up properly in /etc/alternatives/
I can't switch to it easily, what's the problem there?

[root@wiz ~]# alternatives --display java
java - status is auto.
 link currently points to /usr/java/SUNAppserver/jdk/jre/bin/java
/usr/java/SUNAppserver/jdk/jre/bin/java - priority 1500
 slave rmiregistry: /usr/java/SUNAppserver/jdk/jre/bin/rmiregistry
 slave jre_exports: (null)
 slave jre: /usr/java/SUNAppserver/jdk/jre
/usr/java/SUNAppserver/jdk/bin/java - priority 1480
 slave rmiregistry: /usr/java/SUNAppserver/jdk/bin/rmiregistry
 slave jre_exports: (null)
 slave jre: (null)
Current `best' version is /usr/java/SUNAppserver/jdk/jre/bin/java.

Also, sun provide this libjavaplugin_oji.so for my browser. How do I plugin to 
my browser now or isn't this used anymore?

Comment 14 Nitin Kumar Bansal 2007-10-22 08:27:10 UTC
NOTABUG afaik.

This seems to be a bug with java
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373

From Josh Triplett

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.



Comment 15 HughieB 2007-10-23 10:36:09 UTC
sed fix works for me but, What is it about the old libX11 that made it work?

Comment 16 Adam Jackson 2007-11-06 22:40:03 UTC
(In reply to comment #15)
> sed fix works for me but, What is it about the old libX11 that made it work?

The old libX11 would allow you to do things that weren't thread-safe.  The new
one doesn't.

Comment 17 Laurence Vanek 2007-11-14 03:33:32 UTC
what about retail software with its own java on the install media?  I have some
of this that cannot be reinstalled.  The "sed" fix produces no joy in this case.
 Technically it may be a java bug but I am betting we are going to need to find
a way to be tolerant within the operating system.

Comment 18 Luis A. Florit 2007-11-15 21:40:54 UTC
(In reply to comment #17)
> what about retail software with its own java on the install media?  I have 
some
> of this that cannot be reinstalled.  The "sed" fix produces no joy in this 
case.
>  Technically it may be a java bug but I am betting we are going to need to 
find
> a way to be tolerant within the operating system.

Indeed, this 'sed' patch 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 libX11.1.0.3, install Maple, update libX11, and 
patch the Maple libmawt.so.

Comment 19 santiago angel 2007-11-16 08:47:39 UTC
for other awt libs  (e.g. motif) add the following to the "sed" fix:

For sun-java6-bin:

# sed -i 's/XINERAMA/FAKEEXTN/g'
/usr/lib/jvm/java-1.6.0-sun-1.6.0.03/jre/lib/i386/xawt/libmawt.so
# sed -i 's/XINERAMA/FAKEEXTN/g'
/usr/lib/jvm/java-1.6.0-sun-1.6.0.03/jre/lib/i386/motif21/libmawt.so
# sed -i 's/XINERAMA/FAKEEXTN/g'
/usr/lib/jvm/java-1.6.0-sun-1.6.0.03/jre/lib/i386/libawt.so
# sed -i 's/XINERAMA/FAKEEXTN/g'
/usr/lib/jvm/java-1.6.0-sun-1.6.0.03/jre/lib/i386/client/libjvm.so
# sed -i 's/XINERAMA/FAKEEXTN/g'
/usr/lib/jvm/java-1.6.0-sun-1.6.0.03/jre/lib/i386/libjawt.so



Comment 20 Zaptac 2007-11-22 13:27:08 UTC
(In reply to comment #17)
>  Technically it may be a java bug but I am betting we are going to need to find
> a way to be tolerant within the operating system.

Seems to be done in rawhide:
yum --enablerepo=development update libxcb
works for me

Comment 21 Dhaval Giani 2007-11-24 03:00:10 UTC
(In reply to comment #20)

[dhaval@gondor ~]$ rpm -qv libxcb-devel
libxcb-devel-1.1-1.fc9
[dhaval@gondor ~]$ rpm -qv libxcb
libxcb-1.1-1.fc9
[dhaval@gondor ~]$ 

[dhaval@gondor ~]$ opera 
Locking assertion failure.  Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x686777]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0x6868d1]
#2 /usr/lib/libX11.so.6(_XReply+0xff) [0xba912f]
#3 /opt/IBMJava2-142/jre/bin/libawt.so(XineramaIsActive+0x6a) [0x42297a]
#4 /usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN21QDesktopWidgetPrivate4initEv+0x1fa)
[0x60612fa]
#5
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN14QDesktopWidget11resizeEventEP12QResizeEvent+0x25)
[0x6061365]
#6 /usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN7QWidget5eventEP6QEvent+0x266) [0x61600a6]
#7
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN12QApplication14internalNotifyEP7QObjectP6QEvent+0x9b)
[0x60ba38b]
#8
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x97)
[0x60bb967]
#9
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN12QApplication16sendPostedEventsEP7QObjecti+0x169)
[0x60bb419]
#10 /usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN14QDesktopWidgetC1Ev+0x7b) [0x6060adb]
#11 /usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN12QApplication7desktopEv+0x42) [0x60ba232]
#12
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN12QApplication9constructERiPPcNS_4TypeE+0xc5)
[0x60bfa45]
#13 /usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN12QApplicationC2ERiPPc+0x73) [0x60bff93]
#14 /usr/lib/opera/9.22-20070716.6/opera [0x86477a9]
#15 /usr/lib/opera/9.22-20070716.6/opera [0x8060cb2]
#16 /usr/lib/opera/9.22-20070716.6/opera(_ZN7QWidget6createEmbb+0x554) [0x805ec94]
#17 /lib/libc.so.6(__libc_start_main+0xe0) [0x9b4390]
#18 /usr/lib/opera/9.22-20070716.6/opera(_ZNK7QDialog15minimumSizeHintEv+0x111)
[0x805eb71]
opera: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted
[dhaval@gondor ~]$ 

Doesn't seem to work for me.

Comment 22 darrell pfeifer 2007-11-24 03:32:16 UTC
Doesn't work for me either, also with the current rawhide libxcb and various Sun
javas.

Another casualty is recordmydesktop

https://bugzilla.redhat.com/show_bug.cgi?id=397241


Comment 23 Tom Horsley 2007-11-26 18:00:01 UTC
If libxcb requires "proper" multi-threaded locking in programs that are
single threaded, then it IS a bug in libxcb. No amount of hand waving
or assertions to the contrary will change that fact :-). 

Comment 24 Benny 2007-11-26 22:49:39 UTC
If Maple and Maple-Like programs who ship their "own" Java still crash on this
bug how come its closed?

Comment 25 Matěj Cepl 2007-11-27 13:58:51 UTC

*** This bug has been marked as a duplicate of 390261 ***

Comment 26 Matěj Cepl 2007-11-27 13:59:26 UTC
(In reply to comment #24)
> If Maple and Maple-Like programs who ship their "own" Java still crash on this
> bug how come its closed?

go to 390261, that's where the life is.