Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: Running automation tests on an Eclipse RCP for 48+ hours and the exception occured steadily (at least twice a day). Please refer to the stacktrace. More information: eclipse.buildId=unknown java.version=1.6.0_06 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -os win32 -ws win32 -arch x86 -data C:\clister\test\FAST\Workspaces\dogfood_stress Error Wed Apr 01 09:32:52 PDT 2009 Unhandled event loop exception org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:3777) at org.eclipse.swt.SWT.error(SWT.java:3695) at org.eclipse.swt.SWT.error(SWT.java:3666) at org.eclipse.swt.widgets.Widget.error(Widget.java:463) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:336) at org.eclipse.swt.custom.CTabItem.getControl(CTabItem.java:705) at org.eclipse.swt.custom.CTabFolderLayout.layout(CTabFolderLayout.java:76) at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1144) at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1151) at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1151) at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1151) at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1151) at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1151) at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1151) at org.eclipse.swt.widgets.Composite.layout(Composite.java:624) at org.eclipse.swt.widgets.Display.runSettings(Display.java:3872) at org.eclipse.swt.widgets.Display.messageProc(Display.java:3089) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2371) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3420) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2382) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346) 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 com.fnfr.svt.rcp.Application.runWorkbench(Application.java:211) at com.fnfr.svt.rcp.Application.start(Application.java:196) 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(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:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
Does it work if you run the failure test alone ? Maybe try a different VM or a different version of SWT (ie. SWT 3.5 M6) ? Steve, any ideas what can be the problem ?
I see Display.runSettings() on the stack. This means that a system setting was getting changed sometime during the execution of the RCP application. The line in CTabFolderLayout.layout() is bogus: Control control = folder.items[folder.selectedIndex].getControl(); if (control != null && !control.isDisposed()) { control.setBounds(folder.getClientArea()); } It uses API to the control, then test for it being disposed. If the control can be disposed, then the getControl() will fail. The question is, when a control is disposed in a CTabFolder, do we attempt to clean it up from the CTabFolderItem or just check for a disposed control everytime we access it? Someone needs to look at the code, decide and then fix all places
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
