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-1.7.0.0-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-2.5.0.4-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:
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.
thanks - I had the same issue - resolved with workaround. cheers
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.
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.
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.
Filed upstream: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=72
Fixed upstream
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).
Can we be sure to fix this for Fedora 8 please?
Created attachment 221391 [details] error report file
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 "$@"
*** Bug 254144 has been marked as a duplicate of this bug. ***
*** Bug 344591 has been marked as a duplicate of this bug. ***
*** Bug 357471 has been marked as a duplicate of this bug. ***
*** Bug 365911 has been marked as a duplicate of this bug. ***
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.
(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.
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.
(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.
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..
(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.
FWIW, upstream libxcb 1.1 seems to have a similar LIBXCB_ALLOW_SLOPPY_LOCK workaround included in non-NDEBUG builds.
*** Bug 383331 has been marked as a duplicate of this bug. ***
*** Bug 383821 has been marked as a duplicate of this bug. ***
*** Bug 370711 has been marked as a duplicate of this bug. ***
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 libX11.1.0.3, install Maple, update libX11, and patch the Maple libmawt.so.
*** Bug 387071 has been marked as a duplicate of this bug. ***
*** Bug 386321 has been marked as a duplicate of this bug. ***
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
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.
*** Bug 381861 has been marked as a duplicate of this bug. ***
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 :-(.
libxcb-1.0-4.fc8 seems to have fixed this bug; I believe it can be closed.
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-2.0.0.10-3.fc8 [ivo@sarmax ~]$ rpm -qa|grep java ant-javamail-1.7.0-1jpp.2.fc8 java-1.7.0-icedtea-demo-1.7.0.0-0.19.b21.snapshot.fc8 java-1.7.0-icedtea-1.7.0.0-0.19.b21.snapshot.fc8 eclipse-mylyn-java-2.0.0-9.fc8 tzdata-java-2007j-1.fc8 java-1.7.0-icedtea-plugin-1.7.0.0-0.19.b21.snapshot.fc8 java-1.5.0-gcj-devel-1.5.0.0-17.fc8 java-1.7.0-icedtea-javadoc-1.7.0.0-0.19.b21.snapshot.fc8 java-1.5.0-gcj-1.5.0.0-17.fc8 java_cup-0.10-0.k.6jpp.1 gcc-java-4.1.2-33