Hide Forgot
Description of problem: rawhide: eclipse crash with XPCOM error Version-Release number of selected component (if applicable): eclipse-platform-3.4.1-14.fc11.x86_64 How reproducible: always Steps to Reproduce: 1. run eclipse 2. 3. Actual results: error Expected results: no error Additional info: !ENTRY org.eclipse.osgi 4 0 2009-02-03 13:49:07.779 !MESSAGE Application error !STACK 1 org.eclipse.swt.SWTError: XPCOM error -2147467262 at org.eclipse.swt.browser.Mozilla.error(Mozilla.java:1638) at org.eclipse.swt.browser.Mozilla.setText(Mozilla.java:1861) at org.eclipse.swt.browser.Browser.setText(Browser.java:737) at org.eclipse.ui.internal.intro.impl.presentations.BrowserIntroPartImplementation.generateContentForPage(BrowserIntroPartImplementation.java:252) at org.eclipse.ui.internal.intro.impl.presentations.BrowserIntroPartImplementation.dynamicStandbyStateChanged(BrowserIntroPartImplementation.java:451) at org.eclipse.ui.internal.intro.impl.presentations.BrowserIntroPartImplementation.doStandbyStateChanged(BrowserIntroPartImplementation.java:658) at org.eclipse.ui.internal.intro.impl.model.AbstractIntroPartImplementation.standbyStateChanged(AbstractIntroPartImplementation.java:249) at org.eclipse.ui.internal.intro.impl.model.IntroPartPresentation.standbyStateChanged(IntroPartPresentation.java:443) at org.eclipse.ui.intro.config.CustomizableIntroPart.standbyStateChanged(CustomizableIntroPart.java:266) at org.eclipse.ui.internal.ViewIntroAdapterPart$2.run(ViewIntroAdapterPart.java:74) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.ui.internal.ViewIntroAdapterPart.setStandby(ViewIntroAdapterPart.java:70) at org.eclipse.ui.internal.ViewIntroAdapterPart$1.propertyChanged(ViewIntroAdapterPart.java:55) at org.eclipse.ui.internal.WorkbenchPartReference.fireInternalPropertyChange(WorkbenchPartReference.java:374) at org.eclipse.ui.internal.WorkbenchPartReference.fireZoomChange(WorkbenchPartReference.java:539) at org.eclipse.ui.internal.PartPane.setZoomed(PartPane.java:349) at org.eclipse.ui.internal.PartStack.setZoomed(PartStack.java:1526) at org.eclipse.ui.internal.PartSashContainer.zoomIn(PartSashContainer.java:884) at org.eclipse.ui.internal.PartSashContainer.childRequestZoomIn(PartSashContainer.java:905) at org.eclipse.ui.internal.LayoutPart.requestZoomIn(LayoutPart.java:354) at org.eclipse.ui.internal.PartStack.setState(PartStack.java:1501) at org.eclipse.ui.internal.WorkbenchPage.setState(WorkbenchPage.java:3872) at org.eclipse.ui.internal.WorkbenchPage.toggleZoom(WorkbenchPage.java:3944) at org.eclipse.ui.internal.WorkbenchIntroManager.setIntroStandby(WorkbenchIntroManager.java:201) at org.eclipse.ui.internal.WorkbenchIntroManager.showIntro(WorkbenchIntroManager.java:136) at org.eclipse.ui.application.WorkbenchWindowAdvisor.openIntro(WorkbenchWindowAdvisor.java:173) at org.eclipse.ui.internal.ide.application.IDEWorkbenchWindowAdvisor.openIntro(IDEWorkbenchWindowAdvisor.java:458) at org.eclipse.ui.internal.WorkbenchWindow.open(WorkbenchWindow.java:777) at org.eclipse.ui.internal.Workbench$20.runWithException(Workbench.java:1041) at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3378) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3036) at org.eclipse.ui.application.WorkbenchAdvisor.openWindows(WorkbenchAdvisor.java:803) at org.eclipse.ui.internal.Workbench$25.runWithException(Workbench.java:1361) at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3378) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3036) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2293) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
Mozilla's APIs must have changed. I'll see if there's something we can back-port from upstream HEAD. Would you mind trying out a 3.4.1 upstream download on rawhide and seeing if it also fails? http://download.eclipse.org/eclipse/downloads/drops/R-3.4.1-200809111700/index.php You can just download x86 or x86_64 as you prefer. Then just extract it and run ./eclipse/eclipse -data /tmp/testBug483832 I don't have a rawhide box at my disposal ATM. If you could test this build too that would rock: http://download.eclipse.org/eclipse/downloads/drops/S-3.5M5-200902021535/index.php then the same as above: ./eclipse/eclipse -data /tmp/testBug483832-3.5stream Thanks!
Created attachment 330789 [details] 3.4.1 data
Created attachment 330790 [details] 3.5 data
Same crash with both versions from upstream.
Thanks for doing that testing, Jerry! Alex has a new build of Eclipse going in rawhide so let's see if that fixes it: http://koji.fedoraproject.org/koji/buildinfo?buildID=81495 After we know if that fixes it or not, I can speak with upstream.
Created attachment 331142 [details] Crash with eclipse-platform-3.4.1-15.fc11.x86_64
Thanks very much for doing this, Jerry. I'll take this up with upstream and post a link to the bug when I get it filed.
I made a comment at this bug and Grant (upstream Mozilla/SWT guy) is taking a look. https://bugs.eclipse.org/bugs/show_bug.cgi?id=262929 It looks like it's a breaking API change in Xulrunner and may be similar to/the same as: https://bugs.eclipse.org/bugs/show_bug.cgi?id=213194
The trace gives the appearance of a mozilla api change, but I've verified in the xulrunner nightly from a few days ago that the interface hasn't changed, and setText() did still work for me. I haven't tried this on 64-bit yet because it needs to be compiled from source (I'm waiting on our 64-bit RHEL5 box to become available). However I don't think this will show any difference.
I have a 64-bit rawhide (what will become Fedora 11) virtual machine if there's something I can test, Grant.
Assuming it crashes for you the same way, it would be good to know what the xulrunner version is. I will try with the same xulrunner built from source when I get a chance, to see if it could be a problem with the xulrunner in rawhide (doesn't seem likely with an error like this, but needs to be tried).
Mine crashes the same way. I have: $ rpm -q xulrunner xulrunner-1.9.1-0.7.beta2.fc11.x86_64
Sigh, it does look like a changed interface after all. I got an unofficial xulrunner 1.9.1 SDK from http://starkravingfinkle.org/blog/2009/01/unofficial-xulrunner-191-builds/ and nsIDocShell's IID has changed again. I thought thought I'd seen a discussion indicating that these would be held constant within major xulrunner revisions (ie.- until 1.10 or 2.0). If I find it then I'll bring this up on the newsgroup. If 1.9.1 ultimately ships with a changed interface then swt will have to release a change to 3.5 that can use it.
*** Bug 485366 has been marked as a duplicate of this bug. ***
*** Bug 486384 has been marked as a duplicate of this bug. ***
Ok, Bug 486384 might be a duplicate, but I would like to point out that the log there shows other stacktraces before the XPcom one. Just in case it matters and you missed that. Is there a workaround? Can I actually use/test eclipse somehow?
The other stack traces are caused by this. Thanks, though, I went and looked again just to make sure. And thanks for the proper use of -debug -consolelog :) . As a workaround for first-time startup of a new workspace (the welcome screen uses the browser component which is causing the problem), try this: echo "org.eclipse.ui/showIntro=false" > /tmp/noWelcomeScreen.ini eclipse -pluginCustomization /tmp/noWelcomeScreen.ini Please let me know if that works.
A workaround to make the Browser work for you in general is to use a pre-1.9.1-stream xulrunner. You can do this by downloading one and pointing at it by adding a -vmargs -Dorg.eclipse.swt.browser.XULRunnerPath=... switch when launching eclipse (see http://www.eclipse.org/swt/faq.php#specifyxulrunner ). Slightly off-topic, I've brought up the dancing interfaces issue on a mozilla newsgroup, and it seems like the only good solution is to not rely on detecting a xulrunner at runtime. The discussion is at http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/ebea2ae035d14bd9 .
I can confirm that this does indeed work with the showIntro=false option above. I haven't been able to test with an earlier xulrunner yet, but will when I get a chance.
*** Bug 488897 has been marked as a duplicate of this bug. ***
*** Bug 490313 has been marked as a duplicate of this bug. ***
Triaged. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
To solve the problem just need to upgrade firefox yum upgrade firefox discribed here: http://dhartford.blogspot.com/2008/11/eclipse-on-fedora-9.html
(In reply to comment #23) > To solve the problem just need to upgrade firefox > yum upgrade firefox > discribed here: http://dhartford.blogspot.com/2008/11/eclipse-on-fedora-9.html This bug pertains to rawhide, not Fedora 9. BTW, I have built RPMs with the patch Grant kindly posted upstream and am testing them now.
Thanks to Grant from upstream I have a build going now with a patch for this issue. Hopefully it'll hit tomorrow's rawhide. It's eclipse-3.4.2-7.
I'm testing the 3.4.2-7 build now in a Fedora 11 (beta) virtual machine. The welcome screen comes up and the internal browser works. In fact, I'm using the internal browser to write this comment :) I'm going to close this.