Community
Participate
Working Groups
Build Identifier: M20110909-1335 Trying to click 'webbrowser' setting in preferences makes eclipse coredump. Pointing eclipse to all mozilla-like browsers, seamonkey of 2 series and firefox of 3.5, 4, 5 series (by way of environment variables MOZILLA_FIVE_HOME and LD_LIBRARY_PATH) doesn't help. Only the offending function in browser changes. I'm attaching four hs_err*log files, one for each type of browser. The platform is fairly fresh slackware, with jdk 6u20 (alternatively, 6u27) installed. BTW, it happens both in recent eclipse, 3.7.1 (M20110909-1335), and in 2 years old 3.5.0 (I20090611-1540), too. Reproducible: Always Steps to Reproduce: 1. Launch eclipse 2. Open window->preferences 3. expand general category on the left 4. click webbrowser
Created attachment 206254 [details] coredump for seamonkey 2.0.4
Created attachment 206255 [details] coredump for firefox 5.0.1
Created attachment 206256 [details] coredump for firefox 4.0.1
Created attachment 206257 [details] coredump for firefox 3.6.17
I think you need to use WebKit instead.
What I need is Eclipse IDE not coredumping if one of its own general settings is clicked.
The Browser does not attempt to support Seamonkey versions > 1.x or Firefox versions > 3.x, so three of these four are not surprising. The MOZILLA_FIVE_HOME thing is quite old and is only expected to be used for mozilla releases pre-dating xulrunner (versions < 1.8). If your linux distro is reasonably new then it should have WebKitGTK libraries available, and they should be all that's needed to make the Browser happy in your case. What is the installed version of webkitgtk?
Now you have me confused. I already gathered as much, that there is something un-eclipse-satisfactory with my installed browsers. Also, I do not think I have 'webkit' installed, not like what you seem to be talking about. I have libQtWebKit.so.* in my ld cache, though. However, all said, why do I have to be punished that severely? Eclipse might say 'nyar nyar' or refuse to act or something, instead it coredumps. And all I do is click on the preferences item named 'WebBrowser', which is quite a logical choice for click in the modern programs.
Agreed, if a usable native browser is not found then eclipse should just fail to show the Browser, it should not crash. The crash in your case indicates that it's finding something that it either thinks it can embed or is being explicitly pointed at. Which, if any, of the attached coredumps come from the case of running eclipse 3.7.1 with no value specified for MOZILLA_FIVE_HOME or added to LD_LIBRARY_PATH? This is the important case to consider. If your /usr/lib does not have libwebkit.so.* but does have libQtWebKit.so.* then I assume you're running under KDE, and webkitgtk may be available as an optional package to install. If it is then this would be the ideal means of getting this to work. If the webkitgtk package is not available to you then another path is to download xulrunner from http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/3.6.23/runtimes/ , extract it somewhere, and run ./xulrunner --register-global.
So, using this piece of insight, I was finally able to click 'WebBrowser' preference without Eclipse crashing. Thank you, Grant! The xulrunner by itself was of no help, but recent WebKit *and* recent ICU library did the trick. With those two installed Eclipse now gives no trouble either with default MOZILLA_*/LD_* values, or with 2 kinds of xulrunner and 3 kinds of mozilla additionally selectable on my system. Thanks again. However, your (and my) remark stands -- it's still inappropriate behaviour for Eclipse to crash in this way if something's not found on system.
> However, your (and my) remark stands -- it's still inappropriate behaviour > for Eclipse to crash in this way if something's not found on system. To confirm, before you added the libraries, eclipse was crashing for you even when no MOZILLA_FIVE_HOME or LD_LIBRARY_PATH was specified? If it crashed when values for these were specified then that's fine because it's assumed that these will point at a valid (supported) native browser. However if these are not specified then it definitely should not crash.
Well, the MOZILLA_FIVE_HOME setting (to Seamonkey location) actually is included in my login environment. If run without it, by way of env -u MOZILLA_FIVE_HOME ./eclipse, Eclipse makes no trouble, even with WebKit removed from system. However, I've already played with the setting, and as I'm incapable of removing said preferences selectively, I can't test with 'clean' reinstall at the moment. Hope you make of this info more than I do. :)
> the MOZILLA_FIVE_HOME setting (to Seamonkey location) actually is > included in my login environment Wow, I haven't heard of this before. I'm changing the report title accordingly. This seems like a strange thing for the distro to do, but I'll need to research it a bit (do other apps use this?) before figuring out what the right thing to do is.
In fact, said workaround (*either* run with MOZILLA_FIVE_HOME unset *or* with WebKit and its dependencies installed) applies to a similar problem in at least another application using the Eclipse engine -- Unicore Rich client. I've checked this with the client 6.4.1 right now.
Also, similar problem (crash on clicking web browser) occurs in Aptana Studio 3.0.6 for linux 32-bit (also eclipse-based). In this case, however, neither `env -u' nor dependencies for Eclipse do the trick. Here's the top of the stack trace: Stack: [0xbf889000,0xbf8d9000], sp=0xbf8d6530, free space=309k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libxpcom_core.so+0x52512] NS_IsNativeUTF8()+0x1a2 C [libxpcom_core.so+0x52833] NS_CopyUnicodeToNative(nsAString_internal const& , nsACString_internal&)+0xb3 C [libxpcom_core.so+0x5ac82] NS_NewLocalFile_P+0x32 C [libxpcom.so+0x2764] NS_NewLocalFile+0x24 C [libswt-mozilla-gtk-3659.so+0x6d3a] Java_org_eclipse_swt_internal_mozilla_X PCOM__1NS_1NewLocalFile+0x52 j org.eclipse.swt.internal.mozilla.XPCOM._NS_NewLocalFile(II[I)I+0 j org.eclipse.swt.internal.mozilla.XPCOM.NS_NewLocalFile(II[I)I+10 j org.eclipse.swt.browser.Mozilla.initXPCOM(Ljava/lang/String;Z)V+21
Mozilla/xulrunner support will not see further work as latest versions are not embeddable.
