You are not logged in.
After a recent package update, eclipse began crashing with alarming frequency. After some research, it seems eclipse (helios) doesn't yet support xulrunner 2 yet firefox 4 now uses xulrunner 2.
What I'm wondering is
1) Has anyone else come across this issue?
2) Is my diagnosis at all accurate?
I'm looking for a way to resolve this and am checking if anyone else has any insight.
Thanks.
Offline
Following the advice from http://blog.dmaggot.org/2010/12/using-w … se-helios/, I added the following line to /usr/share/eclipse/eclipse.ini:
-Dorg.eclipse.swt.browser.UseWebKitGTK=true
This seems to be doing the trick, in that operations that were previously crashing eclipse are not causing any trouble.
Last edited by vigilandy (2011-03-23 03:29:49)
Offline
Thanks, that also works for me.
Offline
Thanks, works for me too
Offline
Following the advice from http://blog.dmaggot.org/2010/12/using-w … se-helios/, I added the following line to /usr/share/eclipse/eclipse.ini:
-Dorg.eclipse.swt.browser.UseWebKitGTK=true
This seems to be doing the trick, in that operations that were previously crashing eclipse are not causing any trouble.
Same here as well.. Thanks!
Offline
This doesnt work for me . First I solved it by downgrading xulrunner to 1.9* and it worked again, but today I got an update for gnome-shell and it seems that gnome-shell requires xulrunner 2.0 (otherwise it won't start). I tried adding -Dorg.eclipse.swt.browser.UseWebKitGTK=true at the end of eclipse.ini, but it didn't seem to change anything.
db@kirodema ~ $ LANG=en_GB eclipse
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x619045a2, pid=9555, tid=3077756608
#
# JRE version: 6.0_24-b07
# Java VM: Java HotSpot(TM) Client VM (19.1-b02 mixed mode linux-x86 )
# Problematic frame:
# C [libxul.so+0xc395a2]
#
# An error report file with more information is saved as:
# /home/db/hs_err_pid9555.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
/usr/bin/eclipse: line 4: 9555 Aborted ${ECLIPSE_HOME}/eclipse "$@"
As it seems, eclipse only crashes as soon as the auto-completion is kicking in but I can't say that for sure.
Edit:
I found out, that you have to change the xulrunnerpath in eclipse.ini https://bugs.archlinux.org/task/23392#comment73883
Add the following line and it should work if the WebKitGTK solution isn't working for you
-Dorg.eclipse.swt.browser.XULRunnerPath==/usr/lib/xulrunner-2.0/
Last edited by Kirodema (2011-03-29 19:47:29)
Offline
Thanks, I was just about to get angry.
Offline
I'm using the testing repo and I can confirm that setting eclipse to use WebKitGTK in the ini fixes the crashes I was experiencing when using the autocomplete.
Thanks for suggestion.
Offline
setting eclipse to use WebKitGTK in the ini fixes the crashes for me too
Offline
To all - there's no real need to keep confirming that this fix works, it just needlessly bumps the thread. If someone would take this issue up with eclipse upstream (because that's the correct place for it) that would be good, for the meantime this easy workaround is available.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
For some reason the WebKitGTK fix stopped working for me (maybe could have a little something to do with upgrading to gnome3 from testing), but changing the xulrunner path, as Kidorema suggested above, fixed the issue again...
How come this is upstream problem, isn't the location of files handled in the packaging process? (not that I know anything about packaging)
edit.
...so gnome update brakes the WebKitGTK for eclipse (I have libwebkitgtk-1.0 and libwebkitgtk-3.0 around, but here http://www.eclipse.org/swt/faq.php they say that it works with libwebkitgtk-1.2 and higher).
Last edited by aparaatti (2011-04-20 06:46:09)
Offline
Following the advice from http://blog.dmaggot.org/2010/12/using-w … se-helios/, I added the following line to /usr/share/eclipse/eclipse.ini:
-Dorg.eclipse.swt.browser.UseWebKitGTK=true
This seems to be doing the trick, in that operations that were previously crashing eclipse are not causing any trouble.
Thanks, this seems to have fixed it for me. Was searching for a solution for a while.
Offline
This fix is not working now, after I installed Gnome3.
:: Python powered FOREVER ::
Offline
This fix is not working now, after I installed Gnome3.
The latest libwebkit is also not compatible with eclipse.
Try replacing
-Dorg.eclipse.swt.browser.UseWebKitGTK=true
with
-Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner-2.0/
Offline
Replacing the UseWebKitGTK flag with the XULRunnerPath flag fixed eclipse again for me too. Thank you!
Offline
Actually, you could replace the "/usr/lib/xulrunner-2.0" path with anything. Because Eclipse do not support xulrunner2, the internal browser will be disable anyway.
Last edited by dikei (2011-05-02 17:43:24)
Offline
since gnome3 the webkit library name changed from libwebkit-1.0.so to libwebkitgtk-1.0.so, so I did
ln -s libwebkitgtk-1.0.so libwebkit-1.0.so.2
and
-Dorg.eclipse.swt.browser.UseWebKitGTK=true
works again
Offline
Thanks theDOC, that's fixed it again for me.
The browser works and eclipse not crashing.
Offline
since gnome3 the webkit library name changed from libwebkit-1.0.so to libwebkitgtk-1.0.so, so I did
ln -s libwebkitgtk-1.0.so libwebkit-1.0.so.2
and
-Dorg.eclipse.swt.browser.UseWebKitGTK=true
works again
It didn't work for me (also tried making a symbolic link as libwebkit-1.0.so)
any suggestion?
Offline
This fix is not working now, after I installed Gnome3.
Did you solved it? Thx.
Offline
theDOC wrote:since gnome3 the webkit library name changed from libwebkit-1.0.so to libwebkitgtk-1.0.so, so I did
ln -s libwebkitgtk-1.0.so libwebkit-1.0.so.2
and
-Dorg.eclipse.swt.browser.UseWebKitGTK=true
works again
It didn't work for me (also tried making a symbolic link as libwebkit-1.0.so)
any suggestion?
I registered just to say ... Thank you!!!
Offline
since gnome3 the webkit library name changed from libwebkit-1.0.so to libwebkitgtk-1.0.so, so I did
ln -s libwebkitgtk-1.0.so libwebkit-1.0.so.2
and
-Dorg.eclipse.swt.browser.UseWebKitGTK=true
works again
This is the only solution of all the ones mentioned here that worked.
This should be reported upstream, it seems like a really silly bug, bug with eclipse-htmleditor, the editor won't even load without this fix.
Offline
Has this been posted as a bug? I could not find it in the bug database.
Best regards
Martin
Offline
What about gnome 3?
Offline
since gnome3 the webkit library name changed from libwebkit-1.0.so to libwebkitgtk-1.0.so, so I did
ln -s libwebkitgtk-1.0.so libwebkit-1.0.so.2
This kind of fix has been destroying linux installations since the advent of shared libraries. In three days you will have forgotten about that link. But next time a piece of software on your machine looks for that library will think it found the version it was looking for while the one it actually found may export completely different symbols. Do this more regularly and your system will crash and behave randomly in no time and you will never be able to track this down. That's when you see people leaving their 'shitty' distro behind because 'I was just using it normally and all of a sudden, nothing worked - assholes'.
I work with eclipse a lot and often need more than one installation of it in different versions. On Windows that's no problem but on Linux, at least using a package manager it is. The only way we found it to work reliably across different distros and over major- the same as minor updates is to download the binary distribution of eclipse and tar -x it to /opt. We usually create a group 'eclipse' and chown the path to it. That way, every user on a system can use, update and modify it easily. And no distro update will monkey with that installation.
Offline