Bug 254144
Summary: | java Assertion `c->xlib.lock' failed | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | HughieB <nojunk311> | ||||
Component: | libX11 | Assignee: | Søren Sandmann Pedersen <sandmann> | ||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | urgent | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | 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
HughieB
2007-08-24 13:39:04 UTC
Installed IcedTea. Tried a few Java Swing/AWT applications. They work without the lock problem. 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. 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. Downgrading to libX11-1.0.3 "fixes" this issue as well: http://koji.fedoraproject.org/koji/buildinfo?buildID=1730 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.
Same xlib error trying to vmware-user that's part of VMware Tools. 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? Fixed comment #5 in libX11 1.1.3-1.fc8. 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. Reporter, which java it is (i.e., what is the output of java -version on your computer)? 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? 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 *** 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? 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. sed fix works for me but, What is it about the old libX11 that made it work? (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. 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. (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. 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 (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 (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. 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 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 :-). If Maple and Maple-Like programs who ship their "own" Java still crash on this bug how come its closed? *** This bug has been marked as a duplicate of 390261 *** (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. |