Community
Participate
Working Groups
Build Identifier: Version: Juno Release Build id: 20120614-1722 (Eclipse for parallel application developers) When in the workbench, if I click on Help > Welcome or Help > Help Contents, the IDE crashes. Reproducible: Always Steps to Reproduce: 1. Start the IDE (it brings me directly to the workbench now) 2. Click on Help > Welcome or Help > Help Contents
Created attachment 218692 [details] Log file created when the problem occurs May be this log file is useful to understand the problem on your side
The crash is happening in the Mozilla Browser and it is most likely because of a xulrunner version mismatch. Which version of Mozilla Firefox and Xulrunner are you using? Can you please verify that a supported version of Xulrunner or Webkit is installed and used by Eclipse as documented here? - http://www.eclipse.org/swt/faq.php#browserlinux and http://www.eclipse.org/swt/faq.php#browserwebkitgtk
CentOS/RHEL 5.8 does not provide a native browser that's supported by the Browser control, so a workaround that can be used is to download a supported XULRunner (download link: xulrunner-10.0.2.en-US.linux-x86_64.tar.bz2), extract it, and point at it by setting Java's org.eclipse.swt.browser.XULRunnerPath property (related FAQ entry: http://www.eclipse.org/swt/faq.php#specifyxulrunner ). Your crash log indicates that it's currently trying to use /usr/lib64/xulrunner-2, which presumably is an install of XULRunner 2.x. The Browser should not be attempting to do this, it should just fail to instantiate but not crash. Are you doing anything to explicitly point at /usr/lib64/xulrunner-2 (eg.- setting Linux's MOZILLA_FIVE_HOME environment variable? Or Java's org.eclipse.swt.browser.XULRunnerPath property?)?. Or does your OS come with Linux's MOZILLA_FIVE_HOME environment variable set to this?
*** Bug 384592 has been marked as a duplicate of this bug. ***
*** Bug 385232 has been marked as a duplicate of this bug. ***
*** Bug 383993 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > ...Are you doing anything to explicitly point at > /usr/lib64/xulrunner-2 (eg.- setting Linux's MOZILLA_FIVE_HOME environment > variable? Or Java's org.eclipse.swt.browser.XULRunnerPath property?)?. Or > does your OS come with > Linux's MOZILLA_FIVE_HOME environment variable set to this? anyone?
I don't believe that that environment variable is set on my system. I'm also not using a 64 bit machine.
Ok, follow-up question for anyone that sees this problem: Do you have one of the following files, and if so does its content point at the xulrunner-2 dir? /etc/gre64.conf /etc/gre.d/gre64.conf /etc/gre.conf /etc/gre.d/gre.conf
(In reply to comment #7) > (In reply to comment #3) > > ...Are you doing anything to explicitly point at > > /usr/lib64/xulrunner-2 (eg.- setting Linux's MOZILLA_FIVE_HOME environment > > variable? Or Java's org.eclipse.swt.browser.XULRunnerPath property?)?. Or > > does your OS come with > > Linux's MOZILLA_FIVE_HOME environment variable set to this? > > anyone? Sorry ... I've been on vacation up to now. I've not done anything explicitly and I didn't know of the existence of that environment variable. Simply, all previous Eclipse versions worked (and continue to work) with the same settings and Indigo does not.
(In reply to comment #10) > (In reply to comment #7) > > (In reply to comment #3) > > > ...Are you doing anything to explicitly point at > > > /usr/lib64/xulrunner-2 (eg.- setting Linux's MOZILLA_FIVE_HOME environment > > > variable? Or Java's org.eclipse.swt.browser.XULRunnerPath property?)?. Or > > > does your OS come with > > > Linux's MOZILLA_FIVE_HOME environment variable set to this? > > > > anyone? > > Sorry ... I've been on vacation up to now. > > I've not done anything explicitly and I didn't know of the existence of that > environment variable. > Simply, all previous Eclipse versions worked (and continue to work) with the > same settings and Indigo does not. Sorry ... I mean that Juno does not work with the same settings (Indigo, and all previous versions, work)
(In reply to comment #9) > Ok, follow-up question for anyone that sees this problem: Do you have one of > the following files, and if so does its content point at the xulrunner-2 dir? > > /etc/gre64.conf > /etc/gre.d/gre64.conf > /etc/gre.conf > /etc/gre.d/gre.conf I don't have any of these files
I don't know why it's trying to use the xulrunner-2 directory. - I've tried on 64-bit RHEL 5.8 and the Browser successfully avoids it - I've tried on 64-bit RHEL 6.2 (should be similar to CentOS 6.2 and Scientific Linux 6.2), and it comes with WebKitGTK and XULRunner versions that are both supported by the Browser. There shouldn't be a need to fall back to something in a place called "xulrunner-2". Still thinking about what could be happening...
*** Bug 389761 has been marked as a duplicate of this bug. ***
None of these files exist on my system: /etc/gre64.conf /etc/gre.d/gre64.conf /etc/gre.conf /etc/gre.d/gre.conf I'm getting crashes in Eclipse 3.7 and 3.8 now when trying to do ctrl+space on an import, as well as 4.2 I'm using Scientific Linux 6.3.
I notice that Ubuntu 12.10 only provides a GTK 3-based WebKit lib by default, but not the GTK 2-based WebKit lib needed by the Browser. I'm wondering if distros like CentOS 6.x and Scientific Linux 6.x are doing something similar. If you're on one of these, please see if /usr/lib/ contains a libwebkitgtk-1.0.so.0 link to a similarly-named lib in the same directory? This is what the Browser needs. If you only have a libwebkitgtk-3.0.so.0 link there then installing the libwebkitgtk-1.0 package (may not be the exact package name) should fix your problem.
I'm on SL6.3, and at the moment I don't have any files that match /usr/lib/libwebkit* After installing the package, though, a quick 5 minute attempt at reproducing the crash seems to show that the issue's fixed... Can someone else corroborate?
I've just tried, on my CentOS 5, to download any update (there are no updates). The issue is still there.
I was told that this bug covers my problem. I have none listed files. I am running Red hat 5.8 and Eclipse 4.2
[mjones@cmx070 ~]$ ls /usr/lib/libweb* /usr/lib/libwebkit-1.0.so.2 /usr/lib/libwebkit-1.0.so.2.17.8 [mjones@cmx070 ~]$ lsb_release -a LSB Version: :core-4.0-ia32:core-4.0-noarch:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-ia32:printing-4.0-noarch Distributor ID: Scientific Description: Scientific Linux release 6.3 (Carbon) Release: 6.3 Codename: Carbon [mjones@cmx070 ~]$ uname -a Linux cmx070 2.6.32-279.9.1.el6.i686 #1 SMP Tue Sep 25 14:55:22 CDT 2012 i686 i686 i386 GNU/Linux
*** Bug 397782 has been marked as a duplicate of this bug. ***
I tried this again, this time with CentOS 5.8, and I still don't see the crash. This release has XULRunner 1.9.2 by default, which Eclipse works fine with. After applying the CentOS 5.8 auto-updates the XULRunner version was bumped up to XULRunner 10, which Eclipse does not detect and therefore does not crash with (Eclipse would actually not crash even if it did detect the XULRunner 10 because this coincidentally is a supported version). My only remaining guess is that those that see this have taken a different path than me to get to the Linux release they're on. For example, rather than downloading RHEL/CentOS 5.8, someone that started with RHEL/CentOS 5.0 and migrated it to 5.8 over the years via RHEL updates could have some baggage left in their OS image that a clean install of 5.8 would not have (?).
Yes. I've started with CentOS 5.0 and I've continuously upgraded through the standard CentOS upgrade program. Anyway, Eclipse Indigo still works. Eclipse Juno does not.
I started with RHEL 5.8, did an update the Red hat requested. The version of xulrunner is xulrunner - 2. i posted log files but you closed that bug.
I backed out updates to xulrunner until I got to version 1.9.2 and Eclipse works. Eclipse should work with newer versions as well! #yum downgrade xulrunner
I just updated a RHEL 6.1 system to RHEL 6.3 and started seeing this problem. I now have XUL RPMs installed: xulrunner-10.0.11-1.el6_3.x86_64 xulrunner10-10.0.1-1.el6.remi.x86_64 I tried a yum downgrade but it complains that Firefox and other programs require the more recent versions of xulrunner. I am running a Juno build of Eclipse. Is there a workaround that does not involve downgrading xulrunner? thanks, nbc
(In reply to comment #28) Installing the libwebkitgtk-1.0 package (may not be the exact package name) should make this work.
libwebgtk does not exist for CentOS 5.x. It's for Fedora.
I'm running RHEL 6.x and libwebkit did not seem to exist. But I did install webkitgtk (both the 32 and 64 bit versions) and I have not seen the crash since that time yesterday afternoon... nbc
*** Bug 377367 has been marked as a duplicate of this bug. ***
If I am understanding this thread correctly, the workaround suggested up to this point seems to be to use webkit rather than xulrunner, is that correct? If so, is there any workaround if I want to continue using xulrunner?
(In reply to comment #33) > If so, is there any workaround if I want to continue using xulrunner? You need to: 1. Download a supported XULRunner, such as one from http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/10.0.4esr/runtimes/ . 2. Set -Dorg.eclipse.swt.browser.XULRunnerPath=<pathToXULRunner>, details: http://www.eclipse.org/swt/faq.php#specifyxulrunner . 3. Set -Dorg.eclipse.swt.browser.DefaultType=mozilla , details: http://www.eclipse.org/swt/faq.php#browserspecifydefault .
*** Bug 414782 has been marked as a duplicate of this bug. ***
Running into this with 4.2 on RHEL. Is this problem fixed in more recent versions of Eclipse? Any chance of a fix on 4.2.x? We have customers running into this often. We end up suggesting the XULRunner or WebKit workaround to them because there is seems to be nothing we can pre-configure before we ship our product. Our customers are not impressed.
I recently installed Eclipse 4.4SR2 as an upgrade to Juno release, and had problems with it crashing shortly after starting to use it. I eventually tracked it down to one of several activities: - displaying the "Javadoc" view - displaying one of the "Help" menus (as described in this bug) - Pressing Ctrl-Shift-J to try autogenerating Javadoc. Googling around for that brought me through a chain of duplicates, and eventually to this bug. The workaround Grant suggested does indeed fix the problem, and I can actually use Eclipse. (In reply to Grant Gayed from comment #34) > You need to: > 1. Download a supported XULRunner, such as one from > http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/10.0.4esr/runtimes/ > . > 2. Set -Dorg.eclipse.swt.browser.XULRunnerPath=<pathToXULRunner>, details: > http://www.eclipse.org/swt/faq.php#specifyxulrunner . > 3. Set -Dorg.eclipse.swt.browser.DefaultType=mozilla , details: > http://www.eclipse.org/swt/faq.php#browserspecifydefault . For further information related to my setup: > /usr/bin/xulrunner -version Mozilla XULRunner 17.0.9 - 20130918225600 > lsb_release -i -r Distributor ID: RedHatEnterpriseClient Release: 5.4 > usr/bin/firefox -version Mozilla Firefox 31.5.3 It's not immediately clear why or how this solves the problem, or why I need this workaround in the first place, but it looks like this bug has been open for several years now and it's still not fixed. Having Eclipse crash out of the gate on Linux is a terrible customer experience that should be fixed without the customer having to search for some esoteric workaround.
> I eventually tracked it down to one of several activities: > - displaying the "Javadoc" view > - displaying one of the "Help" menus (as described in this bug) > - Pressing Ctrl-Shift-J to try autogenerating Javadoc. I had the same problem this week (Linux Mint 17.3 Rosa, eclipse.buildId=4.5.1.M20150904-0015, java.version=1.8.0_66) The workaround in https://bugs.eclipse.org/bugs/show_bug.cgi?id=410739#c3 works for me (to switch the SWT browser to mozilla).
Now, I can't reproduce the problem anymore. Neither with Mars (Mars.2 Release 4.5.2 - 20160218-0600) nor Neon (Neon Milestone 7 4.6.0M7 - 20160505-1310). I don't know why the bug has disappeared. One of my changes in the meantime was an update of the Lombok javaagent to 16.8; that also fixed the issues mentioned in https://github.com/rzwitserloot/lombok/issues/872. Could there be a connection between lombok and the Javadoc browser problems?
*** This bug has been marked as a duplicate of bug 410739 ***
