Red Hat Bugzilla – Bug 1006273
Fedora 19 breaks ZendStudio
Last modified: 2013-09-22 08:37:52 EDT
with openjdk-1.7 on F17/F18 no problem and after yet updated to F19 i get this errors:
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated.
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.
# A fatal error has been detected by the Java Runtime Environment:
# SIGSEGV (0xb) at pc=0x00007f7075af09b1, pid=13010, tid=140123399988992
# JRE version: OpenJDK Runtime Environment (7.0_60) (build 1.7.0_60-mockbuild_2013_09_06_14_00-b00)
# Java VM: OpenJDK 64-Bit Server VM (24.0-b56 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libsoup-2.4.so.1+0x6d9b1] soup_session_feature_detach+0x11
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
# An error report file with more information is saved as:
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug
This looks like a duplicate of bug 1003209. F19 ships with newer webkit, which upstream Eclipse only supports in Kepler onwards (and zend studio may be based on older Eclipse platform). I suggest to try the workarounds described in the referenced bug and also report the problem upstream (i.e. zend studio).
Feel free to re-open if you think otherwise. If so, please explain why. Thanks!
*** This bug has been marked as a duplicate of bug 1003209 ***
i do not see any workarounds in the referenced bugreport
also report upstream: this is ZendStudio9 and even ZendStudio10 is *not* ship Kepler because of the missing QA of this release resulting in horrible performance which maybe fixed in updates now but a commercial application will *not* rebase the Eclipse platform within a minor update
so you tell me Fedora 19 is unuseable for web-developers?
i do *not* expect such a horrible breakage in case upgrade from "1:java-1.7.0-openjdk-18.104.22.168-22.214.171.124.fc18.x86_64" to "1:java-1.7.0-openjdk-126.96.36.199-188.8.131.52.fc19.x86_64" because it suggests to be a *identical* package
(In reply to Harald Reindl from comment #2)
> i do not see any workarounds in the referenced bugreport
> also report upstream: this is ZendStudio9 and even ZendStudio10 is *not*
> ship Kepler because of the missing QA of this release resulting in horrible
> performance which maybe fixed in updates now but a commercial application
> will *not* rebase the Eclipse platform within a minor update
These are rather harsh words for Kepler. FWIW the performance of Kepler is better than Juno(which was slower than previous releases) from my experience. Especially in regards of the SWT GTK port which received a number of important fixes and improvements (incl. performance).
So I question this statement until someone comes with hard numbers and reproducer so the slower parts can be identified and improved.
Another thing is that the problem is that old Eclipse is not capable of working with new webkitgtk which is a prerequisite for the major desktop environments in Fedora. There was no way that Fedora stays with old webkitgtk and as a result old Gnome and many more and old Eclipse when there was newer Eclipse that worked fine with the new webkitgtk.
> so you tell me Fedora 19 is unuseable for web-developers?
No. Please see http://www.eclipse.org/swt/faq.php#browserspecifydefault . Your best bet would be to download one of the supported firefox/xulrunner releases (http://www.eclipse.org/swt/faq.php#browserlinux) and set it as default as described in the first link.
(In reply to Harald Reindl from comment #3)
> additional note:
> i do *not* expect such a horrible breakage in case upgrade from
> "1:java-1.7.0-openjdk-184.108.40.206-220.127.116.11.fc18.x86_64" to
> "1:java-1.7.0-openjdk-18.104.22.168-22.214.171.124.fc19.x86_64" because it suggests to
> be a *identical* package
The breakage you have seen has nothing to do with the jvm itself. It's about old Eclipse(SWT) calling webkitgtk in inappropriate way causing the whole jvm to crash - the jvm is the victim here.
Hope that helps to understand the problem
> These are rather harsh words for Kepler. FWIW the performance of Kepler
> is better than Juno (which was slower than previous releases) from my
well, that something compared with Juno has a better performance is not that hard, it's like many "improvements" in the opensource-world in the last years "make things as worse as possible which was better before and after that improve them and find enough people which are glad about improvements whiche are none in reality"
> Studio 10 Beta release was built on top of Eclipse 4.2 but for
> better performance we decided to use Eclipse 3.8 for the official release
I'm always welcoming everyone that states something is not hard to show us how to make it even better by sending us the patches :).