Bugzilla – Full Text Bug Listing
| Summary: | eclipse crashes during startup when using new workspace | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | John Cartwright <john.c.cartwright> | ||||
| Component: | IDE | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> | ||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||
| Severity: | critical | ||||||
| Priority: | P3 | CC: | grant_gayed, remy.suen, yue | ||||
| Version: | 3.4 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Please see bug 213194 for the Mozilla error. The widget errors may or may not be resolved as a side effect. (In reply to comment #1) > Please see bug 213194 for the Mozilla error. The widget errors may or may not > be resolved as a side effect. > Thanks, I certainly see the similarities in the bug reports and tried installing a older version (1.8.1.3) of xulrunner and pointing to it: ./eclipse -vm /extra/contrib/jdk1.6.0_06-64/bin/java -Dorg.eclipse.swt.browser.XULRunnerPath=/extra/contrib/xulrunner/xulrunner Same problem and even with the latest 1.9 build. Do I understand that bug 213194 exists in the final ganymede release? --john (In reply to comment #2) > Do I understand that bug 213194 exists in the final ganymede release? No, it should've been fixed. I think we need someone from SWT here. (In reply to comment #2) > Same problem and even with the latest 1.9 build. By latest build you mean a stable build, right? If you uninstall XULRunner, does it run? If you then install Firefox 3 final does it run? The bottom stack in the attachment definitely looks like bug 213194. Your command line in comment 2 is missing the -vmargs switch, it should be: ./eclipse -vm /extra/contrib/jdk1.6.0_06-64/bin/java -vmargs -Dorg.eclipse.swt.browser.XULRunnerPath=/extra/contrib/xulrunner/xulrunner To see which xulrunner/firefox is being found you can try the following: - ./eclipse -vm ... -vmargs -Dorg.eclipse.swt.browser.XULRunnerPath=/dev/null - create a Java project and add eclipse/plugins/org.eclipse.swt.gtk...jar to its Build Path - create and run the following, and see what is written to stdout: import org.eclipse.swt.SWT; import org.eclipse.swt.browser.Browser; import org.eclipse.swt.graphics.Device; import org.eclipse.swt.widgets.*; public class DisplayMozillaVersion { public static void main(String[] args) { Device.DEBUG = true; Display display = new Display(); Shell shell = new Shell(display); System.out.println(">>>Snippet creating SWT.MOZILLA-style Browser"); try { new Browser(shell, SWT.MOZILLA); System.out.println(">>>succeeded"); } catch (Error e) { System.out.println(">>>This failed with the following error:"); e.printStackTrace(); System.out.println("\n\nSnippet creating SWT.NONE-style Browser"); try { new Browser(shell, SWT.NONE); System.out.println(">>>succeeded"); } catch (Error e2) { System.out.println(">>>This failed too, with the following error:"); e.printStackTrace(); } } display.dispose(); } } (In reply to comment #4) > (In reply to comment #2) > > Same problem and even with the latest 1.9 build. > > By latest build you mean a stable build, right? If you uninstall XULRunner, > does it run? If you then install Firefox 3 final does it run? > Yes, "Mozilla XULRunner 1.9.0.1pre - 2008062608". It did not run w/ the xulrunner installed w/ RHEL 5's system version (1.9b5 - 2008042803). FireFox 3 final is installed. --john (In reply to comment #5) > The bottom stack in the attachment definitely looks like bug 213194. Your > command line in comment 2 is missing the -vmargs switch, it should be: > > ./eclipse -vm /extra/contrib/jdk1.6.0_06-64/bin/java -vmargs > -Dorg.eclipse.swt.browser.XULRunnerPath=/extra/contrib/xulrunner/xulrunner > > To see which xulrunner/firefox is being found you can try the following: > > - ./eclipse -vm ... -vmargs -Dorg.eclipse.swt.browser.XULRunnerPath=/dev/null > - create a Java project and add eclipse/plugins/org.eclipse.swt.gtk...jar to > its Build Path > - create and run the following, and see what is written to stdout: > > import org.eclipse.swt.SWT; > import org.eclipse.swt.browser.Browser; > import org.eclipse.swt.graphics.Device; > import org.eclipse.swt.widgets.*; > public class DisplayMozillaVersion { > public static void main(String[] args) { > Device.DEBUG = true; > Display display = new Display(); > Shell shell = new Shell(display); > System.out.println(">>>Snippet creating SWT.MOZILLA-style Browser"); > try { > new Browser(shell, SWT.MOZILLA); > System.out.println(">>>succeeded"); > } catch (Error e) { > System.out.println(">>>This failed with the following error:"); > e.printStackTrace(); > System.out.println("\n\nSnippet creating SWT.NONE-style Browser"); > try { > new Browser(shell, SWT.NONE); > System.out.println(">>>succeeded"); > } catch (Error e2) { > System.out.println(">>>This failed too, with the following > error:"); > e.printStackTrace(); > } > } > display.dispose(); > } > } > Thanks Grant. Using the correct syntax for specifying xulrunner allows eclipse to start w/ either xulrunner 1.8.1.3_0000000000 or 1.9.0.1pre - 2008062608. Running the example above specifying xulrunner 1.90pre on the command-line produces: >>>Snippet creating SWT.MOZILLA-style Browser cannot use detected XULRunner: /usr/lib/xulrunner-1.9pre >>>This failed with the following error: org.eclipse.swt.SWTError: No more handles [Failed to use detected XULRunner: /usr/lib/xulrunner-1.9pre] at org.eclipse.swt.SWT.error(SWT.java:3803) at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:300) at org.eclipse.swt.browser.Browser.<init>(Browser.java:118) at DisplayMozillaVersion.main(DisplayMozillaVersion.java:14) Snippet creating SWT.NONE-style Browser cannot use detected XULRunner: /usr/lib/xulrunner-1.9pre Mozilla path: /usr/lib64/xulrunner-1.9pre >>>succeeded running it w/ xulrunner 1.8.x specified produces the same result: >>>Snippet creating SWT.MOZILLA-style Browser cannot use detected XULRunner: /usr/lib/xulrunner-1.9pre >>>This failed with the following error: org.eclipse.swt.SWTError: No more handles [Failed to use detected XULRunner: /usr/lib/xulrunner-1.9pre] at org.eclipse.swt.SWT.error(SWT.java:3803) at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:300) at org.eclipse.swt.browser.Browser.<init>(Browser.java:118) at DisplayMozillaVersion.main(DisplayMozillaVersion.java:14) Snippet creating SWT.NONE-style Browser cannot use detected XULRunner: /usr/lib/xulrunner-1.9pre Mozilla path: /usr/lib64/xulrunner-1.9pre >>>succeeded It seems that this program is ignoring the xulrunner specified on the command line. Also, executing the system-installed xulrunner in /usr/lib64/xulrunner-1.9pre/ shows a version of 1.9b5. --john The Browser is ultimately settling on using your xulrunner in /usr/lib64/xulrunner-1.9pre, but you say that this answers version "1.9b5", which is known to cause the XPCOM error -2147467262. I assume this xulrunner install was aquired by an auto-update mechanism in RHEL5. If you force another update to be done (assuming that one is available that replaces this xulrunner beta install with the final release) then this should start to work for you without pointing at a different xulrunner install via -Dorg.eclipse.swt... Marking report as a duplicate because I'm very sure this is the case. If this problem still happens for you after updating /usr/lib64/xulrunner-1.9pre to the final xulrunner 1.9 release then please follow up here. *** This bug has been marked as a duplicate of bug 213194 *** (In reply to comment #8) > The Browser is ultimately settling on using your xulrunner in > /usr/lib64/xulrunner-1.9pre, but you say that this answers version "1.9b5", > which is known to cause the XPCOM error -2147467262. I assume this xulrunner > install was aquired by an auto-update mechanism in RHEL5. If you force another > update to be done (assuming that one is available that replaces this xulrunner > beta install with the final release) then this should start to work for you > without pointing at a different xulrunner install via -Dorg.eclipse.swt... > > Marking report as a duplicate because I'm very sure this is the case. If this > problem still happens for you after updating /usr/lib64/xulrunner-1.9pre to the > final xulrunner 1.9 release then please follow up here. > > > *** This bug has been marked as a duplicate of bug 213194 *** > OK thanks. Do I understand correctly that eclipse is correctly using the xulrunner specified on the command line, but the test program was ignoring it and going back to the system version? I really appreciate your help! --john > OK thanks. Do I understand correctly that eclipse is correctly using the
> xulrunner specified on the command line, but the test program was ignoring it
Yes, system properties (like those set with -D...) are only applicable within the application instance where they're defined, they're not inheirited by other apps (like DisplayMozillaVersion) that are launched in a separate process. When running an app like DisplayMozillaVersion the -Dorg.eclipse... VM argument can be specified on the launch configuration's Arguments tab.
|
Created attachment 105949 [details] workspace log file Build ID: I20080617-2000 Steps To Reproduce: 1.launch eclipse 2.specify a newly created directory as workspace 3.splash screen gets about 3/4 through loading and crashes. Dialog titled "Eclipse" says: An error has occurred. See the log file in /tmp/ganymede/.metadata/.log Same behavior whether specified empty existing directory or a non-existing directory. More information: Red Hat Linux 5.2, 64-bit jdk1.6.0_06, eclipse-jee-ganymede-linux-gtk-x86_64