Comment 1 Palmer Eldritch 2013-03-03 10:10:30 EST

Keep getting this since updating to 4.2.2 - Windows 7
Notice the Caused by: org.eclipse.swt.SWTException: Widget is disposed
When I get it clicking OK on a gui elementdoes nothing - I have to click again - especially pronounced in the error log itself

eclipse.buildId=M20130204-1200
java.version=1.7.0_09
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.jee.product
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product

Error
Sun Mar 03 16:47:00 EET 2013
Unhandled event loop exception

org.eclipse.e4.core.di.InjectionException: org.eclipse.swt.SWTException: Widget is disposed
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:63)
	at org.eclipse.e4.core.internal.contexts.ContextObjectSupplier$ContextInjectionListener.update(ContextObjectSupplier.java:88)
	at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:107)
	at org.eclipse.e4.core.internal.contexts.EclipseContext.processScheduled(EclipseContext.java:328)
	at org.eclipse.e4.core.internal.contexts.EclipseContext.dispose(EclipseContext.java:173)
	at org.eclipse.e4.ui.internal.workbench.swt.ShellActivationListener$4.widgetDisposed(ShellActivationListener.java:198)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:123)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1058)
	at org.eclipse.swt.widgets.Widget.release(Widget.java:808)
	at org.eclipse.swt.widgets.Widget.dispose(Widget.java:446)
	at org.eclipse.swt.widgets.Decorations.dispose(Decorations.java:448)
	at org.eclipse.swt.widgets.Shell.dispose(Shell.java:715)
	at org.eclipse.jface.window.Window.close(Window.java:335)
	at org.eclipse.jface.dialogs.Dialog.close(Dialog.java:979)
	at org.eclipse.ui.internal.views.log.EventDetailsDialog.close(EventDetailsDialog.java:191)
	at org.eclipse.jface.window.Window.handleShellCloseEvent(Window.java:741)
	at org.eclipse.jface.dialogs.TrayDialog.handleShellCloseEvent(TrayDialog.java:222)
	at org.eclipse.jface.window.Window$3.shellClosed(Window.java:687)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:98)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062)
	at org.eclipse.swt.widgets.Decorations.closeWidget(Decorations.java:309)
	at org.eclipse.swt.widgets.Shell.close(Shell.java:538)
	at org.eclipse.swt.widgets.Shell.traverseEscape(Shell.java:1951)
	at org.eclipse.swt.widgets.Control.traverse(Control.java:4055)
	at org.eclipse.swt.widgets.Control.translateTraversal(Control.java:4032)
	at org.eclipse.swt.widgets.Display.translateTraversal(Display.java:4794)
	at org.eclipse.swt.widgets.Display.filterMessage(Display.java:1276)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3754)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
	at org.eclipse.jface.window.Window.open(Window.java:801)
	at org.eclipse.ui.internal.views.log.EventDetailsDialog.open(EventDetailsDialog.java:180)
	at org.eclipse.ui.internal.views.log.EventDetailsDialogAction.run(EventDetailsDialogAction.java:98)
	at org.eclipse.ui.internal.views.log.LogView$15.doubleClick(LogView.java:535)
	at org.eclipse.jface.viewers.StructuredViewer$1.run(StructuredViewer.java:845)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
	at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
	at org.eclipse.jface.viewers.StructuredViewer.fireDoubleClick(StructuredViewer.java:843)
	at org.eclipse.jface.viewers.AbstractTreeViewer.handleDoubleSelect(AbstractTreeViewer.java:1477)
	at org.eclipse.jface.viewers.StructuredViewer$4.widgetDefaultSelected(StructuredViewer.java:1246)
	at org.eclipse.jface.util.OpenStrategy.fireDefaultSelectionEvent(OpenStrategy.java:249)
	at org.eclipse.jface.util.OpenStrategy.access$0(OpenStrategy.java:246)
	at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:307)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4169)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3758)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1053)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:942)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:588)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:543)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	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:353)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
	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.equinox.launcher.Main.invokeFramework(Main.java:629)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1414)
Caused by: org.eclipse.swt.SWTException: Widget is disposed
	at org.eclipse.swt.SWT.error(SWT.java:4361)
	at org.eclipse.swt.SWT.error(SWT.java:4276)
	at org.eclipse.swt.SWT.error(SWT.java:4247)
	at org.eclipse.swt.widgets.Widget.error(Widget.java:468)
	at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:340)
	at org.eclipse.swt.widgets.Widget.getStyle(Widget.java:665)
	at org.eclipse.e4.ui.css.swt.helpers.SWTStyleHelpers.getSWTWidgetStyleAsString(SWTStyleHelpers.java:33)
	at org.eclipse.e4.ui.css.swt.dom.WidgetElement.computeAttributeSWTStyle(WidgetElement.java:170)
	at org.eclipse.e4.ui.css.swt.dom.WidgetElement.<init>(WidgetElement.java:118)
	at org.eclipse.e4.ui.css.swt.dom.ItemElement.<init>(ItemElement.java:24)
	at org.eclipse.e4.ui.css.swt.dom.CTabItemElement.<init>(CTabItemElement.java:13)
	at org.eclipse.e4.ui.css.swt.dom.SWTElementProvider.createElement(SWTElementProvider.java:82)
	at org.eclipse.e4.ui.css.swt.dom.SWTElementProvider.getElement(SWTElementProvider.java:49)
	at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.getElement(AbstractCSSEngine.java:912)
	at org.eclipse.e4.ui.css.core.dom.ElementAdapter.getElement(ElementAdapter.java:336)
	at org.eclipse.e4.ui.css.swt.dom.CTabFolderElement.item(CTabFolderElement.java:52)
	at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:481)
	at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:405)
	at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:481)
	at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:405)
	at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:481)
	at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:405)
	at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:481)
	at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:405)
	at org.eclipse.e4.ui.css.swt.internal.theme.ThemeEngine.applyStyles(ThemeEngine.java:498)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$10.setClassnameAndId(PartRenderingEngine.java:1207)
	at org.eclipse.e4.ui.workbench.renderers.swt.SWTPartRenderer.setCSSInfo(SWTPartRenderer.java:85)
	at org.eclipse.e4.ui.workbench.renderers.swt.WBWRenderer.styleStack(WBWRenderer.java:176)
	at org.eclipse.e4.ui.workbench.renderers.swt.WBWRenderer.trackActivePart(WBWRenderer.java:145)
	at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	... 74 more

Comment 2 Julian Cromarty 2014-02-18 07:07:26 EST

I keep getting these errors all the time on Luna (4.4). It's incredibly frustrating as they happen very frequently (every half an hour or more), and once it has happened I cannot use most of Eclipse anymore. "Open Type" no longer works, the selection box for keyboard shortcuts with multiple bindings no longer works, the "quick fix" popup no longer does anything when you select a fix, Eclipse can't even be closed because the confirmation dialog doesn't work... Essentially it seems like most of the UI falls apart.

eclipse.buildId=4.4.0.I20140123-1600
java.runtime.name=Java(TM) SE Runtime Environment
java.runtime.version=1.7.0_04-b22
java.version=1.7.0_04
java.vm.info=mixed mode
java.specification.name=Java Platform API Specification
java.vendor=Oracle Corporation

Stacktrace:

!ENTRY org.eclipse.ui 4 0 2014-02-18 11:41:03.979
!MESSAGE Unhandled event loop exception
!STACK 0
org.eclipse.swt.SWTException: Widget is disposed
        at org.eclipse.swt.SWT.error(SWT.java:4441)
        at org.eclipse.swt.SWT.error(SWT.java:4356)
        at org.eclipse.swt.SWT.error(SWT.java:4327)
        at org.eclipse.swt.widgets.Widget.error(Widget.java:476)
        at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:348)
        at org.eclipse.swt.widgets.Widget.addDisposeListener(Widget.java:218)
        at org.eclipse.e4.ui.css.swt.engine.CSSSWTEngineImpl.hookNativeWidget(CSSSWTEngineImpl.java:53)
        at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.getElement(AbstractCSSEngine.java:927)
        at org.eclipse.e4.ui.css.core.dom.ElementAdapter.getElement(ElementAdapter.java:336)
        at org.eclipse.e4.ui.css.swt.dom.CTabFolderElement.item(CTabFolderElement.java:57)
        at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:491)
        at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:415)
        at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:491)
        at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:415)
        at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:491)
        at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:415)
        at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:491)
        at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyStyles(AbstractCSSEngine.java:415)
        at org.eclipse.e4.ui.css.swt.internal.theme.ThemeEngine.applyStyles(ThemeEngine.java:504)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$10.setClassnameAndId(PartRenderingEngine.java:1276)
        at org.eclipse.e4.ui.workbench.renderers.swt.SWTPartRenderer.setCSSInfo(SWTPartRenderer.java:108)
        at org.eclipse.e4.ui.workbench.renderers.swt.WBWRenderer.updateNonFocusState(WBWRenderer.java:594)
        at org.eclipse.e4.ui.workbench.renderers.swt.WBWRenderer.access$5(WBWRenderer.java:571)
        at org.eclipse.e4.ui.workbench.renderers.swt.WBWRenderer$13.handleEvent(WBWRenderer.java:565)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
        at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4353)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1061)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1085)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1066)
        at org.eclipse.swt.widgets.Decorations.WM_ACTIVATE(Decorations.java:1678)
        at org.eclipse.swt.widgets.Shell.WM_ACTIVATE(Shell.java:2151)
        at org.eclipse.swt.widgets.Control.windowProc(Control.java:4607)
        at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:339)
        at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1626)
        at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2075)
        at org.eclipse.swt.widgets.Display.windowProc(Display.java:5020)
        at org.eclipse.swt.internal.win32.OS.PeekMessageW(Native Method)
        at org.eclipse.swt.internal.win32.OS.PeekMessage(OS.java:3141)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3756)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1122)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1006)
        at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:146)
        at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:615)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
        at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:566)
        at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
        at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:125)
        at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:109)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:80)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:372)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:226)
        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:601)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1450)

Comment 3 Daniel Rolka 2014-02-18 10:52:35 EST

(In reply to Julian Cromarty from comment #2)
> I keep getting these errors all the time on Luna (4.4). It's incredibly
> frustrating as they happen very frequently (every half an hour or more), and
> once it has happened I cannot use most of Eclipse anymore. "Open Type" no
> longer works, the selection box for keyboard shortcuts with multiple
> bindings no longer works, the "quick fix" popup no longer does anything when
> you select a fix, Eclipse can't even be closed because the confirmation
> dialog doesn't work... Essentially it seems like most of the UI falls apart.
> 
> eclipse.buildId=4.4.0.I20140123-1600
> java.runtime.name=Java(TM) SE Runtime Environment
> java.runtime.version=1.7.0_04-b22
> java.version=1.7.0_04
> java.vm.info=mixed mode

Could you provide the steps how to recreate the issue?

thanks,
Daniel

Comment 4 Julian Cromarty 2014-02-18 12:06:19 EST

(In reply to Daniel Rolka from comment #3)
> Could you provide the steps how to recreate the issue?
> 
> thanks,
> Daniel

I've yet to find any particular action that causes this behaviour, but I'll keep the error console open and visible while working and note down what I'm doing when the errors occur. If a pattern emerges (or something obvious is at fault) I'll report back.

Cheers

Julian

Comment 5 Julian Cromarty 2014-02-19 07:58:14 EST

Got some more stacktraces. Again, it seems that once it's gone wrong once, it starts failing all over the place. The actions that caused the errors were:

* Pressing OK on the project properties dialog after editing Maven settings, causing a prompt to recompile the project.
* Closing a Maven pom file editor
* Switching focus to eclipse
* Switching focus from eclipse
* Trying to open the "Open type" dialog

Stacktraces attached as a text file.

Comment 6 Julian Cromarty 2014-02-19 07:58:59 EST

Created attachment 240107 [details]
Error stacktraces showing the issue

Comment 7 Daniel Rolka 2014-02-19 08:16:02 EST

(In reply to Julian Cromarty from comment #6)
> Created attachment 240107 [details]
> Error stacktraces showing the issue

Thanks for update. Could you please provide the information about Eclipse version (pure SDK, EE version, RCP version, ...) and the Maven plugin you are using?

thanks,
Daniel

Comment 8 Julian Cromarty 2014-02-19 08:27:04 EST

Created attachment 240109 [details]
Configuration and software versions

(In reply to Daniel Rolka from comment #7)
> Thanks for update. Could you please provide the information about Eclipse
> version (pure SDK, EE version, RCP version, ...) and the Maven plugin you
> are using?

No problem. I'm not sure the best place to find all the versions so I've attached the contents of the "Configuration" tab in the Platform Installation Details window.

Cheers,

Julian

Comment 9 Steven Spungin 2014-04-06 16:23:53 EDT

I have been able to recreate this consistently.  The problem is that it is quantum debugging - setting a breakpoint will prevent it from happening.  There is a race condition with CTabFolder having disposed CTabItems while the CSS Engine renders; It does not happen predictably.

In my case CSSEngine is trying to add a Dispose Listener on a widget that is already disposed.

Now why CSSEngine is not waiting for GUI to finish is TBD, but the solution to avoid the exception it to have the CSSEngine check to see if the element wraps a widget, and if so, ignore it if it is disposed.

Now this lead to the problem that AbstractCSSEngine knows nothing of SWT Widgets, so cannot find out if the object is disposed.

To avoid SWT dependency CSSStylableElement interface needs a method in the nature of -> boolean canStyle() <- or similar that returns false if widget is disposed.  There is already a dispose() method in that interface for the element, so naming it isDisposed() would be vague (dispose for the element vs. the native widget)

To avoid messing with the interface, I suggest allowing NodeList.item() implementation to return null if the CSSStylableElement does not want to be poked.  This would require CSSEngine to be modified with a null check instead of modifying the CSSStylableElement interface.  This is my solution.

Another quick fix for the TabFolderElement would be to adjust returned node length when tab-items are disposed so CSSEngine will query for the disposed items.


---

Has this happened to anyone for classes other than CTabFolder?

Comment 10 Steven Spungin 2014-04-06 16:52:59 EDT

On second thought, item() should never return null, so I put a modification in CTabFolderElement to never return a count higher than it's first disposed CTabItem.

https://git.eclipse.org/r/#/c/24510/1

Comment 11 Steven Spungin 2014-04-07 05:32:43 EDT

from org.eclipse.swt.cocoa.macosx.x86_64.source_3.103.0.v20140401-1156.jar CTabFolder.class

	/*
	 * Usually when an item is disposed, destroyItem will change the size of the items array, 
	 * reset the bounds of all the tabs and manage the widget associated with the tab.
	 * Since the whole folder is being disposed, this is not necessary.  For speed
	 * the inDispose flag is used to skip over this part of the item dispose.
	 */
	inDispose = true;

CTabFolder is not disposed, but has set inDispose to true, and has disposed the CTabItems.  This is why CSSEngine is pulling disposed items out of the array and trying to render them.

Comment 12 Brian de Alwis 2014-04-07 12:45:26 EDT

(In reply to Steven Spungin from comment #9)
> Has this happened to anyone for classes other than CTabFolder?

Comment #0 is about a ToolItem.

Changing CTabFolderElement#getLength() and #item() is a workaround, but not a solution.

Since you have a reproducible workflow, Steven, could you try overriding getElement() in AbstractCSSSWTEngineImpl to spit out the widget hierarchy when the element is an Item and is disposed?  That would help to identify what CTabFolder or ToolBar is causing problems.

Comment 13 Steven Spungin 2014-04-07 13:01:15 EDT

(In reply to Brian de Alwis from comment #12)
> (In reply to Steven Spungin from comment #9)
> > Has this happened to anyone for classes other than CTabFolder?
> 
> Comment #0 is about a ToolItem.
> 
> Changing CTabFolderElement#getLength() and #item() is a workaround, but not
> a solution.
> 
> Since you have a reproducible workflow, Steven, could you try overriding
> getElement() in AbstractCSSSWTEngineImpl to spit out the widget hierarchy
> when the element is an Item and is disposed?  That would help to identify
> what CTabFolder or ToolBar is causing problems.

The last time I looked, the rogue CTabFolder was not even part of the current hierarchy.  It had a very low system id, and just hung around and showed up every time I opened an editor, closed an editor, or switched tabs. 

But I shut down my Eclipse, and now I can't get it back...  That's why I left the trace in there. 

Because the TabItems were disposed, I could not find any text to figure out where it came from.  The odd thing is that I had a breakpoint in the constructor for CTabFolder, but I don't recall it breaking for the disposed parent CTabFolder.

Comment 14 Steven Spungin 2014-04-07 22:26:02 EDT

I have been reading through the preceding stack traces.  There seems to be 2 issues here.

1.  Related to uninject getting called on MParts that have been closed, disposed, but still called via @Inject annotated methods.  I have been lobbying for a solution to prevent parts from getting  @Injection methods until only after the part has been fully instantiated (after @PostConstruct) and not after dispose has been called on the widget.  @PreDestroy is called after widgets are disposed and I am still having a tough time accepting that one.

The current Eclipse solution for this is for @Inject annotated methods accessing widgets to start with a guard that checks both anyWidget != null && anyWidget.isDisposed()==false to ensure they have not been called too early or too late.

My solution is to use a special annotation @PostInject instead of @Inject that is not called until after @PostConstruct and never called after the Part has been disposed.  I am using that solution inhouse, but most here seem to feel it is anti-java and anti-eclipse :( Bug 425186

--- 

2. Related to StyleEngine accessing a TabFolder that disposes it's TabItems but does not remove them from their container array, so GetItemCount still returns them, and getItem returns the disposed widget. Perhaps this tweak is done because the TabItems are not part of the control tree, the comment says it's done for speed, but lucky for us it exposes several other issues:

What is happening is if a control in the TabFolder throws an exception while disposing, the CTabFolder never finishes, and is left undisposed with 0 controls in the control array and all the disposed tab items left in the items array.

There is no way to know about this state unless checking isDisposed() on the first item, or adding an accessor to the member inDispose.

We check for isDisposed() in our workaround, but that doesn't explain why the CTabFolder is there in the first place.  This half-disposed TabFolder never truly gets disposed, and the TabFolderElement forever lives to be perused by the StyleEngine document. 

What cause the half-disposed widget?  An unchecked exception of course.  In my case the TreeViewer of the ModelEditor was calling ObservableListTreeContentProvider.inputChanged in it's dispose method.  Intermittently, it went through 20 stack levels and once in a while threw this assertion:

org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
at org.eclipse.core.databinding.observable.ObservableTracker.getterCalled(ObservableTracker.java:252)

This bubbled up and prevented the CTabFolder from finishing, leaving an array of disposed CTabItems, while preventing the StyleEngine removing the item.


To test this, add the following code to ContentViewer.java, set a breakpoint, and force bad to true when Application Model Editor is closed.

    protected void handleDispose(DisposeEvent event) {
        if (contentProvider != null) {
			boolean bad = false;
			if (bad) {
				throw new RuntimeException("bad, bad boy"); //$NON-NLS-1$
			}
            contentProvider.inputChanged(this, getInput(), null);
            contentProvider.dispose();
            contentProvider = null;
        }

Now notice how an exception will prevent contentProvider.dispose().  And contentProvider manages to sink it's teeth in the part, causing a resource leak. 

All it takes is for the handler to be a bad, bad boy one time, and the CSSEngine hits the workaround forever in a leaked, unfocused part, and we find this error only because the wacky CTabFolder et al left something behind.

So the partial solution is to have CTabFolder clean up after itself by clearing the TabItem array.  That's SWT COCOA, ETC and I am not going there...

And the main solution is that content viewer should always dispose it's content provider even if it misbehaves during the final hurrah.

Here's the patch:
https://git.eclipse.org/r/#/c/24599/

Comment 15 Steven Spungin 2014-04-09 01:02:17 EDT

This appears to have solved at least 5 other issues I have been having for at least 6 months, including windows in the IDE that would not redraw unless resizing, windows that refused to close, and freezes while shutting down.

Comment 16 Brian de Alwis 2014-04-09 10:21:23 EDT

(In reply to Steven Spungin from comment #14)
> What is happening is if a control in the TabFolder throws an exception while
> disposing, the CTabFolder never finishes, and is left undisposed with 0
> controls in the control array and all the disposed tab items left in the
> items array.

Good find!  Do you have a stack trace showing this exception, or a repeatable set of steps?  I think the required solution here is to ensure that this exception is caught and handled during the CTF/CTI disposal: although the problem in ContentViewer looks legitimate, a similar exception in some other widget will lead to the same problem.

Comment 17 Steven Spungin 2014-04-09 10:42:34 EDT

See Bug 432440.  I will be posting a file there you can use to recreate all the issues

This has led me to discover many issues:

CTabFolder revealing disposed widgets
CTabFolder not clearing internal CTabItemList
CTabFolderElement returning disposed widgets
Content Viewer not disposing content provider
CSSEngine using disposed parts returned from elements
DetailObservableSet, WritableSet and ObservableSet not catching assert exception during clear
WritableSet indirectly calling HashCode while making a temporary copy of a set
ObservableCollectionTreeContentProvider not catching exception in inputChanged

In addition, as you look at the stack trace from the assert, you will find several methods that do not catch the exception and fail to release resources (listeners etc).

BTW, I think the ContentViewer issue is Major and should be dealt with ASAP.

Comment 18 Steven Spungin 2014-04-09 11:08:26 EDT

> Good find!  Do you have a stack trace showing this exception, or a
> I think the required solution here is to ensure
> that this exception is caught and handled during the CTF/CTI disposal:
> although the problem in ContentViewer looks legitimate, a similar exception
> in some other widget will lead to the same problem.

An exception in inputchanged during the handleDisposed should not interfere with the chain of dispose events.  Inputchanged has no idea that is being called in the dispose handler, and because is being disposed, I think the exception has no meaning to methods higher in the stack.  It seems to be a 'courtesy call' IMHO, completely unrelated to the dispose action.

Comment 19 Steven Spungin 2014-04-16 01:51:50 EDT

I don't know whose A$$ to light a fire under, but if I was the King of Eclipse, heads would be rolling if this code was allowed to be released in the next I-Build:

 protected void handleDispose(DisposeEvent event) {
        if (contentProvider != null) {
            contentProvider.inputChanged(this, getInput(), null);
            contentProvider.dispose();
            contentProvider = null;
        }
        if (labelProvider != null) {
            labelProvider.removeListener(labelProviderListener);
            labelProvider.dispose();
            labelProvider = null;
        }
        input = null;
    }

As I have demonstrated, if inputChanged() throws an exception, the entire dispose method stack is interrupted.  The resulting resource leaks usually result in terrible things, way beyond the scope of this bug. When my debugger throws the exception, this issue seems to actually affect my running Eclipse, even after the debug session ends.

Yes there are several other issues that could be cleaned up, but catching the exception here is rather passive and I can't imagine it would take to much effort to review.

Comment 20 Paul Webster 2014-04-16 08:51:41 EDT

(In reply to Steven Spungin from comment #19)
> I don't know whose A$$ to light a fire under, but if I was the King of
> Eclipse, heads would be rolling if this code was allowed to be released in
> the next I-Build:

It's been there for almost 10 years, and does not regularly cause problems.  We can certainly make it more robust, but it's not the fire drill that you make it out to be.  I'll look at it later today (despite your hyperbole :-)

> Yes there are several other issues that could be cleaned up, but catching
> the exception here is rather passive and I can't imagine it would take to
> much effort to review.

I can agree that this code should be made more robust.  But the failing client code needs to be fixed.  That's the root of your problem.

PW

Comment 21 Steven Spungin 2014-04-16 09:36:56 EDT

> It's been there for almost 10 years, and does not regularly cause problems. 
> We can certainly make it more robust, but it's not the fire drill that you
> make it out to be.  I'll look at it later today (despite your hyperbole :-)

When I have to restart Eclipse because parts don't redraw, or force quit it because parts don't close, it's a pretty bad situation. 

Do you have any issue with putting a debug statement in the catch block so we can actually get feedback and see how many times this is happening?  I would be surprised if it was limited to just this provider, or e4 in general.  That's why I am sounding the alarm.

In general, there is an overall failure to handle exceptions and clean up resources;  It is not limited to a single function.  Just follow the stack trace and look at how many methods miss the unchecked exception. This is not limited to the provider in question, or the CSSEngine that ultimately realizes the leak.  I think as a general policy, any method in the dispose chain needs to insure that resources will be clean up.  That's more serious than an isolated case of a single client throwing.

The particular provider that led me to this issue was throwing the exception because it is dependent on widgets. Obviously the inputChanged will have issues if called after those widgets are disposed.  But it is not obvious that inputChanged would be called from the dispose method.

In conclusion, it think there are many issues that to be fixed, but shoring up ContentViewer by all means should take priority over any specific client's issues.

Thanks for looking into it!

Comment 22 Paul Webster 2014-04-16 16:01:25 EDT

Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=decc8b08a421bf765f735b4633d82e2cc1f974b0

Thanks Steven.

PW

Comment 23 Steven Spungin 2014-04-17 06:00:39 EDT

Please note that 2 other patches related to this were contributed.

One solves the zombie part issue in the CCSEngine when receiving the exception, and one solves the underlying cause of the exception in the observable provider.

https://git.eclipse.org/r/#/c/24731/
https://git.eclipse.org/r/#/c/24510/

Comment 24 Paul Webster 2014-04-29 11:18:23 EDT

In 4.4.0.I20140428-2000

PW

Comment 25 DaveLaw 2017-04-12 19:11:47 EDT

SWT Version 4623
Eclipse v4.5 (Mars)
I am still experiencing this problem.
SWTException: Widget is disposed
e4 CSS is trying to render a CTabItemElement
But there are NO CTabItems in the GUI Tree!!
There were, but the Composite containing the CTabFolder was disposed.
We get an Error Dialogue, ONCE ONLY...
...then it seems to recover and render the GUI correctly.
How can I
a) turn off e4 CSS?
b) force e4 CSS to rebuild its Style Tree?

Comment 26 DaveLaw 2017-04-13 06:02:11 EDT

Created attachment 267789 [details]
StackTrace showing GUI Controls Tree Structure

Having played around with this some more, I'm now confident its an SWT Bug.
Please see attached file for StackTrace.
(because its better formatted there & easier to digest)

Comment 27 Dani Megert 2017-04-13 06:05:09 EDT

(In reply to DaveLaw Missing name from comment #26)
> Created attachment 267789 [details]
> StackTrace showing GUI Controls Tree Structure
> 
> Having played around with this some more, I'm now confident its an SWT Bug.
> Please see attached file for StackTrace.
> (because its better formatted there & easier to digest)

Please open a new bug to track it.

Comment 28 DaveLaw 2017-04-13 06:22:07 EDT

I think its probably THIS Bug.
Do you want a new Bug anyway?

Comment 29 Dani Megert 2017-04-13 06:38:35 EDT

(In reply to DaveLaw Missing name from comment #28)
> I think its probably THIS Bug.
> Do you want a new Bug anyway?

Yes please. You can refer to this one.

Comment 30 DaveLaw 2017-04-14 02:32:11 EDT

ok, here it is:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=515250