Bug 483832 - rawhide: eclipse can't start - XPCOM error
rawhide: eclipse can't start - XPCOM error
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Andrew Overholt
Fedora Extras Quality Assurance
:
: 485366 486384 488897 490313 (view as bug list)
Depends On:
Blocks: F11Blocker/F11FinalBlocker
  Show dependency treegraph
 
Reported: 2009-02-03 15:15 EST by Jerry Amundson
Modified: 2009-04-03 10:16 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-03 10:16:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
3.4.1 data (3.03 KB, application/octet-stream)
2009-02-03 17:16 EST, Jerry Amundson
no flags Details
3.5 data (3.18 KB, application/octet-stream)
2009-02-03 17:16 EST, Jerry Amundson
no flags Details
Crash with eclipse-platform-3.4.1-15.fc11.x86_64 (2.61 KB, application/octet-stream)
2009-02-06 11:26 EST, Jerry Amundson
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Eclipse Project 213194 None None None Never
Eclipse Project 268651 None None None Never

  None (edit)
Description Jerry Amundson 2009-02-03 15:15:10 EST
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)
Comment 1 Andrew Overholt 2009-02-03 16:33:07 EST
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!
Comment 2 Jerry Amundson 2009-02-03 17:16:06 EST
Created attachment 330789 [details]
3.4.1 data
Comment 3 Jerry Amundson 2009-02-03 17:16:36 EST
Created attachment 330790 [details]
3.5 data
Comment 4 Jerry Amundson 2009-02-03 17:18:05 EST
Same crash with both versions from upstream.
Comment 5 Andrew Overholt 2009-02-04 08:47:50 EST
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.
Comment 6 Jerry Amundson 2009-02-06 11:26:57 EST
Created attachment 331142 [details]
Crash with eclipse-platform-3.4.1-15.fc11.x86_64
Comment 7 Andrew Overholt 2009-02-06 11:42:28 EST
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.
Comment 8 Andrew Overholt 2009-02-10 11:48:25 EST
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
Comment 9 Grant Gayed 2009-02-11 13:54:27 EST
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.
Comment 10 Andrew Overholt 2009-02-11 14:09:03 EST
I have a 64-bit rawhide (what will become Fedora 11) virtual machine if there's something I can test, Grant.
Comment 11 Grant Gayed 2009-02-11 15:20:46 EST
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).
Comment 12 Andrew Overholt 2009-02-12 15:19:51 EST
Mine crashes the same way.  I have:

$ rpm -q xulrunner
xulrunner-1.9.1-0.7.beta2.fc11.x86_64
Comment 13 Grant Gayed 2009-02-12 15:53:15 EST
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.
Comment 14 Andrew Overholt 2009-02-13 08:54:34 EST
*** Bug 485366 has been marked as a duplicate of this bug. ***
Comment 15 Andrew Overholt 2009-02-19 10:43:02 EST
*** Bug 486384 has been marked as a duplicate of this bug. ***
Comment 16 Mads Kiilerich 2009-02-19 10:58:45 EST
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?
Comment 17 Andrew Overholt 2009-02-19 11:41:24 EST
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.
Comment 18 Grant Gayed 2009-02-19 11:48:37 EST
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 .
Comment 19 jtl2011 2009-02-20 18:23:58 EST
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.
Comment 20 Andrew Overholt 2009-03-06 09:23:30 EST
*** Bug 488897 has been marked as a duplicate of this bug. ***
Comment 21 Andrew Overholt 2009-03-15 13:58:23 EDT
*** Bug 490313 has been marked as a duplicate of this bug. ***
Comment 22 Jerry Amundson 2009-03-15 22:46:00 EDT
Triaged.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 23 Yuri Zhloba 2009-04-02 11:16:18 EDT
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
Comment 24 Andrew Overholt 2009-04-02 11:21:48 EDT
(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.
Comment 25 Andrew Overholt 2009-04-02 18:32:15 EDT
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.
Comment 26 Andrew Overholt 2009-04-03 10:16:09 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.