| Summary: | [Helios] Unhandled event loop exception: XPCOM error -2147467262 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Severin Gehwolf <sgehwolf> | ||||
| Component: | SWT | Assignee: | Grant Gayed <grant_gayed> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | blueser, grant_gayed, leander, remy.suen, sgehwolf, Silenio_Quarti | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Severin Gehwolf
BTW. after that error happens it tells me that a SWT error occurred and asks me if I want to restart my workbench. When I say "No" and try "Help Contents" again, the help pages show up in Mozilla Firefox. I've seen unhookDOMListeners() fail before, but always in the context of another error occurring outside of the Browser. This is the first time I've seen it fail in a scenario that may have been working otherwise. Severin can you try: - load SWT with its source into your workspace, either from CVS ( http://www.eclipse.org/swt/cvs.php ) or File > Import... > Plug-ins and Fragments > etc... - insert as the new first line of Mozilla.unhookDOMListeners(): if (true) {System.out.println("running away!"); return;} - self-host (Run > Run As... > Eclipse Application) - in the self-hosted workspace try Help > Help Contents: -> is "running away!" written to stdout, to ensure that it's running with the change? -> does Help now work, and show in a Shell with a Browser control (ie.- not in external Firefox)? (In reply to comment #2) > I've seen unhookDOMListeners() fail before, but always in the context of > another error occurring outside of the Browser. This is the first time I've > seen it fail in a scenario that may have been working otherwise. Severin can > you try: > > - load SWT with its source into your workspace, either from CVS ( > http://www.eclipse.org/swt/cvs.php ) or File > Import... > Plug-ins and > Fragments > etc... > - insert as the new first line of Mozilla.unhookDOMListeners(): > if (true) {System.out.println("running away!"); return;} > - self-host (Run > Run As... > Eclipse Application) > - in the self-hosted workspace try Help > Help Contents: > -> is "running away!" written to stdout, to ensure that it's running with the > change? > -> does Help now work, and show in a Shell with a Browser control (ie.- not > in external Firefox)? Did it. I've got the "running away!" printed. *But* it opens an empty Eclipse window (a window with title "Eclipse SDK", but the content is just white background, nothing in it). The good thing, I didn't get "XPCOM error -2147467262". Thanks! So there is another error happening then, it's not just unhookDOMListeners(). The empty error dialog is logged as bug 234910. Is there anything logged in your workspace to indicate what the original error was? Created attachment 171662 [details] Empty Window Here's a screenshot. It looks like the window opens correctly, but without actual content (the HTML help pages). I don't think it is related to bug 234910. Thoughts? I'm not getting any errors (with the immediate return in unhookDOMListeners() in place). Without it, I'm getting the stack trace as in the original description. I forgot the context, you're invoking Help, so bug 234910 is unrelated. Does the Help->Welcome screen work for you? If so then my guess is that the quick create-then-dispose of a Browser that's done by Help->Contents to determine if the Browser is available or not is causing a problem, though this has not been reported before. Also you mention that you have the Linux Tools installed. I assume the problem still happens with just a plain Eclipse? (In reply to comment #7) > I forgot the context, you're invoking Help, so bug 234910 is unrelated. > > Does the Help->Welcome screen work for you? It doesn't (even with the immediate return in unhookDOMListeners() in place). It produces the same error as described initially. > Also you mention that you have the Linux Tools installed. I assume the problem > still happens with just a plain Eclipse? I haven't tried, yet, but I will and let you know. Note: I'm getting this error even if platform is installed only. I get this error as well every time I try to open a HTML file with CTRL+SHIFT+R. Here I am running fully updated Helios x86_64 on Ubuntu 10.04 with Oracle JDK 6u21 x86_64. Don't know if it's related, but this appears a couple of times on the logs as well:
!ENTRY org.eclipse.ui 4 0 2010-08-02 14:42:25.055
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.NullPointerException
at org.eclipse.jdt.internal.corext.buildpath.ClasspathModifier.getExistingEntries(ClasspathModifier.java:319)
at org.eclipse.jdt.internal.ui.wizards.buildpaths.newsourcepage.NewSourceContainerWorkbookPage.getSelection(NewSourceContainerWorkbookPage.java:311)
at org.eclipse.jdt.internal.ui.wizards.buildpaths.BuildPathsBlock.tabChanged(BuildPathsBlock.java:1018)
at org.eclipse.jdt.internal.ui.wizards.buildpaths.BuildPathsBlock.access$2(BuildPathsBlock.java:1013)
at org.eclipse.jdt.internal.ui.wizards.buildpaths.BuildPathsBlock$1.widgetSelected(BuildPathsBlock.java:278)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3552)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3171)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction.java:117)
at org.tigris.subversion.subclipse.ui.actions.CheckoutUsingProjectWizardAction.getNewProject(CheckoutUsingProjectWizardAction.java:175)
at org.tigris.subversion.subclipse.ui.actions.CheckoutUsingProjectWizardAction.checkoutSingleProject(CheckoutUsingProjectWizardAction.java:106)
at org.tigris.subversion.subclipse.ui.actions.CheckoutUsingProjectWizardAction.execute(CheckoutUsingProjectWizardAction.java:77)
at org.tigris.subversion.subclipse.ui.wizards.CheckoutWizard.checkoutUsingWizard(CheckoutWizard.java:396)
at org.tigris.subversion.subclipse.ui.wizards.CheckoutWizard.performFinish(CheckoutWizard.java:348)
at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:811)
at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:430)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:624)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3552)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3171)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.tigris.subversion.subclipse.ui.actions.CheckoutAsAction.execute(CheckoutAsAction.java:46)
at org.tigris.subversion.subclipse.ui.actions.SVNAction.run(SVNAction.java:56)
at org.eclipse.ui.actions.ActionDelegate.runWithEvent(ActionDelegate.java:70)
at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:241)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3552)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3171)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2629)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2593)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2427)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:670)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:663)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
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:369)
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:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
at org.eclipse.equinox.launcher.Main.main(Main.java:1383)
Wow, now I simply can't run Eclipse on that specific workspace anymore. I even completely removed the workspace (with 'rm -fr') and tried to recreate it from scratch on the startup screen, but it still aborts with: !ENTRY org.eclipse.osgi 4 0 2010-08-04 11:30:24.035 !MESSAGE Application error !STACK 1 org.eclipse.swt.SWTError: XPCOM error -2147467262 at org.eclipse.swt.browser.Mozilla.error(Mozilla.java:2347) at org.eclipse.swt.browser.Mozilla.unhookDOMListeners(Mozilla.java:2777) at org.eclipse.swt.browser.Mozilla.onDispose(Mozilla.java:2370) at org.eclipse.swt.browser.Mozilla$5.handleEvent(Mozilla.java:872) ... Other workspaces still work normally. How can I workaround this? Also, please raise this issue's importance do "Major" since it prevents Eclipse startup. (In reply to comment #12) > Other workspaces still work normally. This is probably because it's loading the 'Welcome' screen on initial startup on a fresh workspace. Whereas, on your other workspaces, that screen has been closed/dismissed. (In reply to comment #13) > (In reply to comment #12) > > Other workspaces still work normally. > > This is probably because it's loading the 'Welcome' screen on initial startup > on a fresh workspace. Whereas, on your other workspaces, that screen has been > closed/dismissed. That's a possibility, indeed. I little more info on this: no matter what I did Eclipse simply wouldn't start on that specific workspace. I even reinstalled Eclipse from scratch, to no avail. Then I googled and found out other people are having the same issue on Ubuntu 10.04: http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=eclipse+won't+start+ubuntu+xpcom Since I could not find any file that would explain why it was not starting, I thought it could be a runtime situation, something got stuck on some lib (Mozilla XULRunner?). I rebooted the computer (looking back I guess a logout would suffice) and then I managed to recreate the workspace again. I hope this gives some more info on this problem, so hopefully someone will come with a solution. IMO this is a serious problem that needs to be adressed ASAP. In case it helps, what I have installed here is xulrunner-1.9.2 Forgot to mention: this post https://garage.maemo.org/tracker/index.php?func=detail&aid=4689&group_id=192&atid=1420 states that passing this parameter to Eclipse -Dorg.eclipse.swt.browser.XULRunnerPath=/dev/null could solve the problem. Can anyone confirm this is indeed a solution and it has no side-effects? (In reply to comment #15) I can not confirm any channges when I apply the option. The problem still persists. Actually in my case it got worse - now Eclipse fails to load on the workspace! (In reply to comment #16) > (In reply to comment #15) > > I can not confirm any channges when I apply the option. The problem still > persists. > > Actually in my case it got worse - now Eclipse fails to load on the workspace! Ups - I did not do it right the first time. It actually did work when I appended -Dorg.eclipse.swt.browser.XULRunnerPath=/dev/null to the end of the eclipse.ini file. I also had success if I assigned the value /usr/bin/xulrunner instead of /dev/null. When I remove the option, the error reappears. I now have to almost identical systems (same fully upgraded Fedora 13, same eclipse build) - one has the problem (without the above fix) - the other seems to be working flawless. If anybody want further configuration information to help fix this problem for good, just drop me an email. re: comments 10-15 -Dorg.eclipse.swt.browser.XULRunnerPath=/dev/null gets around the problem you're seeing as a result of disabling all Browser functionality, so this is a side effect if you depend on Browser controls to work. Most eclipse uses of the Browser work fine if Browser functionality is disabled, content is shown by some other means. On the subject of workarounds, since you're on Ubuntu 10.04 you could use WebKitGTK instead of XULRunner as the native renderer, see http://www.eclipse.org/swt/faq.php#browserwebkitgtk . (In reply to comment #18) > re: comments 10-15 > -Dorg.eclipse.swt.browser.XULRunnerPath=/dev/null gets around the problem > you're seeing as a result of disabling all Browser functionality, so this is a > side effect if you depend on Browser controls to work. Most eclipse uses of > the Browser work fine if Browser functionality is disabled, content is shown by > some other means. Thks for confirming that. One thing I've noticed is that javadoc on hovers is now rendering links (eg. @see tags) as plain text; could this be a side-effect of disabling browser functionality? Or can I enable it somewhere else? > On the subject of workarounds, since you're on Ubuntu 10.04 you could use > WebKitGTK instead of XULRunner as the native renderer, see > http://www.eclipse.org/swt/faq.php#browserwebkitgtk . Thks for the pointer. Unfortunately I could not understand the last two instructions, I suppose they're directed at SWT developers, is that right? I replaced -Dorg.eclipse.swt.browser.XULRunnerPath=/dev/null by -Dorg.eclipse.swt.browser.UseWebKitGTK=true and the XPCOM error resurfaced when I tried to open the javadoc view. Should I have done anything else? > could this be a side-effect of disabling browser functionality? Yes it is > the last two instructions, I suppose they're directed at SWT developers Yes, to run eclipse with WebKitGTK-based Browsers, adding a line with -Dorg.eclipse.swt.browser.UseWebKitGTK=true to the eclipse.ini file before launching eclipse should be adequate. If you're still seeing an XPCOM error then it's still trying to use a mozilla-based native browser. If you're on Ubuntu 10.04 and are specifying the above property correctly then you should get WebKitGTK-based Browsers. (In reply to comment #20) > Yes, to run eclipse with WebKitGTK-based Browsers, adding a line with > -Dorg.eclipse.swt.browser.UseWebKitGTK=true to the eclipse.ini file before > launching eclipse should be adequate. If you're still seeing an XPCOM error > then it's still trying to use a mozilla-based native browser. If you're on > Ubuntu 10.04 and are specifying the above property correctly then you should > get WebKitGTK-based Browsers. I put the -D... definition on my wrapper script, and it seems to be effective: Eclipse configuration shows eclipse.vmargs=-Xms256m -Xmx512m -Dorg.eclipse.swt.browser.UseWebKitGTK=true -XX:MaxPermSize=256m -jar /usr/local/eclipse-3.6.0/eclipse/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar However, if I trigger a javadoc hover eg. by positioning the mouse pointer over a class name Eclipse aborts and this is what appears on stderr: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fd14445c19e, pid=4613, tid=140537666512656 # # JRE version: 6.0_21-b06 # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.0-b16 mixed mode linux-amd64 ) # Problematic frame: # C [libgobject-2.0.so.0+0x2819e] g_type_check_instance_is_a+0xbe # # An error report file with more information is saved as: # /usr/local/eclipse-3.6.0/eclipse/hs_err_pid4613.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # This seems to be 100% reproducible. Should I file a separate issue? In the meantime, I'll switch back to -Dorg.eclipse.swt.browser.XULRunnerPath=/dev/null which seems to be the only configuration working for me so far. re: comment 21 This is bug 323763, which is now fixed, so no need to log a report for it. re: comment 22 Grant: I can see this WebKitGTK SIGSEV is already fixed on 3.6.2, but is there any chance it gets backported to 3.6.1 before 3.6.2 ETA? Feb/2011 is still far ahead, and considering that currently neither XULRunner nor WebKitGTK are working on Ubuntu 10.04[*], this will mean quite some time with limited SWT browser rendering, which is bad. Almost all our company is Ubuntu-based, and all people upgrading to Helios are being forced to use -Dorg.eclipse.swt.browser.XULRunnerPath=/dev/null to avoid this dreadful XPCOM event loop. If this fix won't land on Helios before Feb/2011, could you please point me to the first 3.6.2 build that contains it? Assuming it's still close enough to 3.6.1, I would consider giving it a try. [*] oddly, I don't experience this event loop on Fedora 13 x86_64, which is what I have at home... (In reply to comment #23) > If this fix won't land on Helios before Feb/2011, could you please point me to > the first 3.6.2 build that contains it? You should try any M build later than 20100909-0800. http://download.eclipse.org/eclipse/downloads/ (In reply to comment #24) > (In reply to comment #23) > > If this fix won't land on Helios before Feb/2011, could you please point me to > > the first 3.6.2 build that contains it? > > You should try any M build later than 20100909-0800. > http://download.eclipse.org/eclipse/downloads/ Thks Remy, I'll try M20100929-0800 then. Since I'm not used to download pieces separately, I would like to confirm which ones I need to download for Java development (the ones that make up the "Eclipse IDE for Java Developers" bundle) : is it enough to download only the platform and JDT runtimes? Any others? Andre you can try a couple of things to get WebKitGTK working: - Bug 323763 only affects 64-bit linux installs, so if you have the 32-bit compatibility libraries installed on your machine (you probably do) then you could just try the 32-bit release of Eclipse 3.6.1 along with the -Dorg.eclipse.swt.browser.UseWebKitGTK=true java property. - Alternatively, if you want a 3.6.2-stream build with the 64-bit fix for bug 323763 then you're best to get a recent 3.6.2 build like M20101006-0936, because I don't think swt submitted fixes to the initial 3.6.2 builds. The easiest thing to download for java development is the Eclipse SDK, which is http://download.eclipse.org/eclipse/downloads/drops/M20101006-0936/download.php?dropFile=eclipse-SDK-M20101006-0936-linux-gtk-x86_64.tar.gz . (In reply to comment #25) > Since I'm not used to download pieces separately, I would like to confirm which > ones I need to download for Java development (the ones that make up the > "Eclipse IDE for Java Developers" bundle) : is it enough to download only the > platform and JDT runtimes? Any others? No, it is not. I believe there is package comparison link on the main downloads page which shows a table of what plug-ins are included in what package. Mozilla support will not see further work as recent versions are no longer suitable embeddable browsers and thus are not supported by SWT. |