Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Azureus and all java apps are crashing (xcb_xlib_unlock: Assertion)|
|Product:||[Fedora] Fedora||Reporter:||Ugo Viti <ugo.viti>|
|Component:||java-1.7.0-icedtea||Assignee:||Lillian Angel <langel>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||andreas.kotowicz, anton, bertil, gilboad, jnovy, lvanek, madko, marek78uk, mbogelund, michel, mishu, mmclagan, neugens, nhruby, nojunk311, oehmes, overholt, psquareweblogic, redhat-bugzilla, ville.skytta, vittoso|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-10-12 17:01:40 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||235703, 390261|
Description Ugo Viti 2007-09-22 11:48:12 EDT
Description of problem: Azureus or others java graphical apps crash in the rawhide branch. i "think" the problem is introduced from the usage of libxcb package and reliking of xlibs against it... azureus crash seem related to SWT library... others java apps (tryed IntelliJ IDEA, JXplorer and Aqua Datastudio) crash with the following error: java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed. Tried the following java versions (in order): - Java SUN JDK/JRE 1.6u2 - java-1.5.0-gcj - java-1.7.0-icedtea-18.104.22.168-0.15.b19.snapshot.fc8 - Java SUN JDK/JRE 1.7.0-ea-b20 no java apps are working right now :-) (updated to rawhide 20070922) Version-Release number of selected component (if applicable): azureus-22.214.171.124-2.fc7 Best Regards. UV How reproducible: launch azureus or others java graphical apps Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Comment 1 Ugo Viti 2007-09-22 15:14:42 EDT
i found some links reporting the above problem with a "workaround": http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373 https://bugs.freedesktop.org/show_bug.cgi?id=11390 the workaround: cd $JAVA_HOME/lib/i386/xawt cp libmawt.so libmawt.so-orig sed -i 's/XINERAMA/FAKEEXTN/g' libmawt.so this seem solve the problems with java apps, but disable Xinerama support.
Comment 2 Dan 2007-09-30 04:36:44 EDT
thanks - I had the same issue - resolved with workaround. cheers
Comment 3 Michel Alexandre Salim 2007-10-02 18:04:33 EDT
Moving this to libxcb, since openSUSE has a patch for it that we might want to consider adopting. The bug also affects R's JGR GUI add-on.
Comment 4 Adam Jackson 2007-10-03 15:07:48 EDT
The opensuse patch is not really something I'm comfortable with shipping. XCB has locking assertions for a reason; if they're getting tripped, something is broken. More to the point is this analysis of the bug upstream: https://bugs.freedesktop.org/show_bug.cgi?id=11390#c3 The JDK you're using is broken. It's never been safe, it's just now it's refusing to be unsafe. Fortunately I think we can fix this in icedtea.
Comment 5 Adam Jackson 2007-10-03 15:10:16 EDT
Created attachment 214941 [details] icedtea-use-system-libXinerama.patch This patch to the jdk should make us link against the system libXinerama, which is always built threadsafe. In addition you'll need to add BuildRequires: libXinerama-devel to the specfile.
Comment 6 Thomas Fitzsimmons 2007-10-04 12:21:37 EDT
Filed upstream: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=72
Comment 7 Lillian Angel 2007-10-04 14:09:44 EDT
Comment 8 Mark van Rossum 2007-10-06 09:59:38 EDT
The same problem occurs with Matlab. Matlab uses its own java libraries. The patch fixes it, but you have to apply to the matlab version of the lib. ('locate libmawt.so' to find it).
Comment 9 Adam Jackson 2007-10-08 16:19:52 EDT
Can we be sure to fix this for Fedora 8 please?
Comment 10 Andreas Kotowicz 2007-10-09 11:25:29 EDT
Created attachment 221391 [details] error report file
Comment 11 Andreas Kotowicz 2007-10-09 11:26:57 EDT
Comment on attachment 221391 [details] error report file above patch does fix the startup problem. But if I select a file in Azureus and use the right mouse click option "Show Details" Azureus crashes: # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xb5106e62, pid=3160, tid=3086154640 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_02-b05 mixed mode, sharing) # Problematic frame: # C [libgtkjni-2.8.so+0x7ae62] # # An error report file with more information is saved as hs_err_pid3160.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # /usr/bin/azureus: line 18: 3160 Aborted LD_LIBRARY_PATH=/usr/lib/eclipse:/usr/lib CLASSPATH=/usr/lib/eclipse/swt-gtk-3.3.jar:`build-classpath bcprov jakarta-commons-cli log4j gtk2.8 glib0.2`:/usr/share/azureus/Azureus2.jar java -Dgnu.gcj.runtime.VMClassLoader.library_control=never -Dazureus.install.path=$APPDIR org.gudy.azureus2.ui.swt.Main "$@"
Comment 12 Adam Jackson 2007-10-18 13:41:57 EDT
*** Bug 254144 has been marked as a duplicate of this bug. ***
Comment 13 Adam Jackson 2007-10-22 11:18:36 EDT
*** Bug 344591 has been marked as a duplicate of this bug. ***
Comment 14 Matěj Cepl 2007-10-31 17:55:55 EDT
*** Bug 357471 has been marked as a duplicate of this bug. ***
Comment 15 Anton Keks 2007-11-06 04:15:21 EST
*** Bug 365911 has been marked as a duplicate of this bug. ***
Comment 16 Anton Keks 2007-11-06 04:17:11 EST
Fixing it in icedtea is not an option for Java developers, etc, who need to have multiple older JDK on their system. Please remove the assertions at least temporarily.
Comment 17 Adam Jackson 2007-11-06 17:58:50 EST
(In reply to comment #16) > Fixing it in icedtea is not an option for Java developers, etc, who need to have > multiple older JDK on their system. So much for write once, run anywhere. > Please remove the assertions at least temporarily. No. The asserts are there for a reason. They prevent race conditions that would otherwise be maddening to debug. I'm not going to sacrifice guaranteed correctness for heisenbugs. If you need to work around this for an older JDK, refer to comment #1.
Comment 18 Richard Körber 2007-11-07 16:44:58 EST
I understand that there are good reasons for the assert. Anyhow Java obviously worked all the years before, even with the flaw. As a professional Java developer, I know that it is sometimes difficult or even impossible to apply the workaround mentioned in comment #1, especially if customers are involved. Some software brings its own JVM, or is certified to run only on a concrete Java version, so there is no way to use a Java update with the bug fixed, or IcedTea as a replacement. I propose that instead of the assert, a warning message is dumped, but the function continues as it did before. This would keep the possibility to find race conditions, and would still allow to use older Sun Java installations.
Comment 19 Adam Jackson 2007-11-07 23:01:33 EST
(In reply to comment #18) > I understand that there are good reasons for the assert. Anyhow Java obviously > worked all the years before, even with the flaw. Worked until it didn't, sure. > I propose that instead of the assert, a warning message is dumped, but the > function continues as it did before. This would keep the possibility to find > race conditions, and would still allow to use older Sun Java installations. Install the appropriate rpm from: http://ajax.fedorapeople.org/libxcb/ And run the app with LIBXCB_ALLOW_SLOPPY_LOCK=1 in the environment.
Comment 20 Jon Escombe 2007-11-09 07:43:02 EST
The spec file for those rpm's defines but doesn't apply the patch ;) May be worth pointing out that this is biting things other than Java, also breaks the Citrix ICA client..
Comment 21 Adam Jackson 2007-11-09 14:50:11 EST
(In reply to comment #20) > The spec file for those rpm's defines but doesn't apply the patch ;) Whoops! Fixed. > May be worth pointing out that this is biting things other than Java, also > breaks the Citrix ICA client.. I don't have that handy. I assume it's statically linked to something though? It would be best to have a new bug for that issue.
Comment 22 Ville Skyttä 2007-11-11 16:19:30 EST
FWIW, upstream libxcb 1.1 seems to have a similar LIBXCB_ALLOW_SLOPPY_LOCK workaround included in non-NDEBUG builds.
Comment 23 Matěj Cepl 2007-11-15 10:17:29 EST
*** Bug 383331 has been marked as a duplicate of this bug. ***
Comment 24 Matěj Cepl 2007-11-15 10:18:02 EST
*** Bug 383821 has been marked as a duplicate of this bug. ***
Comment 25 Thomas Fitzsimmons 2007-11-15 13:17:48 EST
*** Bug 370711 has been marked as a duplicate of this bug. ***
Comment 26 Luis A. Florit 2007-11-15 16:35:31 EST
Some programs have their own JAVA installers that unpack from zips.(In reply to comment #1) > i found some links reporting the above problem with a "workaround": > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373 > https://bugs.freedesktop.org/show_bug.cgi?id=11390 > > the workaround: > > cd $JAVA_HOME/lib/i386/xawt > cp libmawt.so libmawt.so-orig > sed -i 's/XINERAMA/FAKEEXTN/g' libmawt.so > > this seem solve the problems with java apps, but disable Xinerama support. This 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 libX126.96.36.199, install Maple, update libX11, and patch the Maple libmawt.so.
Comment 27 Thomas Fitzsimmons 2007-11-16 11:39:04 EST
*** Bug 387071 has been marked as a duplicate of this bug. ***
Comment 28 Matěj Cepl 2007-11-16 18:54:34 EST
*** Bug 386321 has been marked as a duplicate of this bug. ***
Comment 29 Michi 2007-11-17 10:07:29 EST
Hello, I had The same bug. So I used the woraround. This worked probably and all my java applications worked fine again. Now, I wanted to update my BOINC-client form v5.8.2 to 5.10.2 but when I want to start the boincmgr I get again this error. Workaournd dosn't work. As far as I know BOINC is NOT written in Java, but in GKT1 Greetings, Michi
Comment 30 duni.bg 2007-11-18 18:39:29 EST
After updating from Fedora 7 to Fedora 8 Pro Engineer Wildfire 3 fails: pro: xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed. I will give the above rpms a try, but I have to say, that programs like Maple and Matlab, stated above, or ProE, in my case, most likely wouldn't adopt this "change". And those are the programs/companies, who are so kind to ship their professional software for Linux, too. I will please the developers to fix this bug in the upstream so, that those programs can work as they did before.
Comment 31 Jindrich Novy 2007-11-19 07:39:23 EST
*** Bug 381861 has been marked as a duplicate of this bug. ***
Comment 32 Jan Newmarch 2007-12-03 02:10:38 EST
Sun (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373) mark this as "Closed, fixed", saying "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." bugs.freedesktop.org says RESOLVED NOTOURBUG. "...I spoke with Tom Marble of Sun about this at OSCON, and he and I both agreed that this bug lies with the JDK..." Above says "No. The asserts are there for a reason. They prevent race conditions that would otherwise be maddening to debug. I'm not going to sacrifice guaranteed correctness for heisenbugs." So it looks like it's no-one's bug and it won't get fixed. I've tried most of the suggested patches so far and they haven't worked. Whatever works needs to get into the core distro anyway. I guess I had better go back to FC7 and forget about FC8 :-(.
Comment 33 Craig Kelley 2007-12-18 18:23:50 EST
libxcb-1.0-4.fc8 seems to have fixed this bug; I believe it can be closed.
Comment 34 Ivo Sarak 2007-12-27 07:03:59 EST
How do you check if this is fixed? I have libxcb-1.0-4.fc8 installed, but no Java applets are working with Firefox. [ivo@sarmax ~]$ rpm -q firefox firefox-188.8.131.52-3.fc8 [ivo@sarmax ~]$ rpm -qa|grep java ant-javamail-1.7.0-1jpp.2.fc8 java-1.7.0-icedtea-demo-184.108.40.206-0.19.b21.snapshot.fc8 java-1.7.0-icedtea-220.127.116.11-0.19.b21.snapshot.fc8 eclipse-mylyn-java-2.0.0-9.fc8 tzdata-java-2007j-1.fc8 java-1.7.0-icedtea-plugin-18.104.22.168-0.19.b21.snapshot.fc8 java-1.5.0-gcj-devel-22.214.171.124-17.fc8 java-1.7.0-icedtea-javadoc-126.96.36.199-0.19.b21.snapshot.fc8 java-1.5.0-gcj-188.8.131.52-17.fc8 java_cup-0.10-0.k.6jpp.1 gcc-java-4.1.2-33