Community
Participate
Working Groups
3.1 RC1 I don't have any steps to reproduce the problem. I just found this exception in the log file. I was checking out some resources from CVS at this time. But I'm pretty sure that the Package Explore wasn't open in the CVS perspective. !ENTRY org.eclipse.ui 4 4 2005-06-08 15:10:14.334 !MESSAGE Unhandled event loop exception !ENTRY org.eclipse.ui 4 0 2005-06-08 15:10:14.334 !MESSAGE Widget is disposed !STACK 0 org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:2940) at org.eclipse.swt.SWT.error(SWT.java:2863) at org.eclipse.swt.SWT.error(SWT.java:2834) at org.eclipse.swt.widgets.Widget.error(Widget.java:395) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:297) at org.eclipse.swt.widgets.Widget.getData(Widget.java:448) at org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren(AbstractTreeViewer.java:1764) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefreshStruct(AbstractTreeViewer.java:1268) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1245) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1201) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$PackageExplorerProblemTreeViewer.internalRefresh(PackageExplorerPart.java:492) at org.eclipse.jface.viewers.StructuredViewer$8.run(StructuredViewer.java:1291) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1201) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$PackageExplorerProblemTreeViewer.preservingSelection(PackageExplorerPart.java:598) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1289) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider$3.run(PackageExplorerContentProvider.java:615) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider$7.run(PackageExplorerContentProvider.java:659) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:118) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:2906) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2565) at org.eclipse.jface.window.Window.runEventLoop(Window.java:809) at org.eclipse.jface.window.Window.open(Window.java:787) at org.eclipse.team.internal.ccvs.ui.actions.CheckoutAsAction.execute(CheckoutAsAction.java:31) at org.eclipse.team.internal.ccvs.ui.actions.CVSAction.run(CVSAction.java:117) at org.eclipse.ui.actions.ActionDelegate.runWithEvent(ActionDelegate.java:70) at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:236) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:538) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:844) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2929) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2562) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1694) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1658) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:366) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:103) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:375) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:162) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334) at org.eclipse.core.launcher.Main.basicRun(Main.java:278) at org.eclipse.core.launcher.Main.run(Main.java:973) at org.eclipse.core.launcher.Main.main(Main.java:948) !ENTRY org.eclipse.core.resources 2 1 2005-06-08 15:10:14.365 !MESSAGE Skipping builder org.antlr.eclipse.core.antlrbuilder for project net.sourceforge.clearcase. Either the builder is missing from the install, or it belongs to a project nature that is missing or disabled.
Gunnar, any steps to reproduce. And an additional question: was the package explorer open when the exception occurred or was it closed ?
No, sorry. I just found this in the log, while I was investigating another issue in the CVS component. I was in the CVS perspective and the Package Explorer wasn't open there. But it was opend in the Java perspective. There was no popup dialog, thus I didn't realize this error in the UI.
Given that this happened while the package explorer was open points more to a JFace viewer problem (accessing an already disposed item) then to a problem in the package explorer. However without any hint how and when this happens hard to fix. Setting to Remind and CCing Nick to get a opinion from JFace.
It's always possible for a widget to be disposed between the time an asyncExec gets queued and the time it's run. PackageExplorerContentProvider.postRunnable's trackedRunnable should check that the widget hasn't been disposed before running r. Recommend checking other occurrences of asyncExec in JDT.
Nick, as gunnar pointed out the package explorer was still open when the exception happened. So the exception can't come from a already disposed package explorer. Furthermore, the check you mention is already in. The tracked runnable posted in postRunnable typically look like this (for example for the refresh it is) new Runnable() { public void run() { Control ctrl= fViewer.getControl(); if (ctrl != null && !ctrl.isDisposed()) { for (Iterator iter= toRefresh.iterator(); iter.hasNext();) { fViewer.refresh(iter.next(), updateLabels); } } } }
Sorry, I missed that check. So it does look like one of the items is disposed, not the tree itself. The strange thing is that it already successfully iterated over the same items (also using getData()) just prior to that loop in AbstractTreeViewer.updateChildren (see line 1764 of rev 1.65 of AbstractTreeViewer). There are calls to equals, mapElement and disassociate (plus some calls directly on the item), but none of these should dispose the item. Is this still true in the various overrides for the PE?
I looked over the code and we don't dispose any items in the overridden methods. Gunnar, can you comment on whether your top level elements in the package explorer are working sets or projects ?
The top-level elements were projects. But a working set was active at this time.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
