Community
Participate
Working Groups
The asynchronous operations should be aware of being executed after the initialy valid data became invalid. Especially, there shoudn't be any refresh trigger anymore if the platform is shutting down. Occassionally, exceptions like the followings will happen than: Unhandled event loop exception during blocked modal context. org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:3499) at org.eclipse.swt.SWT.error(SWT.java:3422) at org.eclipse.swt.SWT.error(SWT.java:3393) at org.eclipse.swt.widgets.Widget.error(Widget.java:432) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:325) at org.eclipse.swt.widgets.Tree.getItems(Tree.java:3011) at org.eclipse.rse.internal.ui.view.SystemView.smartRefresh(SystemView.java:3244) at org.eclipse.rse.internal.ui.view.SystemView.refreshAll(SystemView.java:3133) at org.eclipse.rse.internal.ui.view.SystemView$ResourceChangedJob.runInUIThread(SystemView.java:1942) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:94) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3650) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3287) at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:158) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:326) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:495) at org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog.run(ProgressMonitorJobsDialog.java:265) at org.eclipse.ui.internal.ide.application.IDEWorkbenchAdvisor.disconnectFromWorkspace(IDEWorkbenchAdvisor.java:404) at org.eclipse.ui.internal.ide.application.IDEWorkbenchAdvisor.postShutdown(IDEWorkbenchAdvisor.java:321) at org.eclipse.ui.internal.Workbench.shutdown(Workbench.java:2650) at org.eclipse.ui.internal.Workbench.busyClose(Workbench.java:902) at org.eclipse.ui.internal.Workbench.access$15(Workbench.java:819) at org.eclipse.ui.internal.Workbench$22.run(Workbench.java:1063) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.ui.internal.Workbench.close(Workbench.java:1061) at org.eclipse.ui.internal.Workbench.close(Workbench.java:1033) at org.eclipse.ui.internal.testing.WorkbenchTestable$2.run(WorkbenchTestable.java:121) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3650) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3287) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2337) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2301) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2176) at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:463) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:458) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at com.windriver.ide.application.CopyOfIDEApplication.start(CopyOfIDEApplication.java:104) at com.windriver.ide.application.UnifiedSWTSwingApplication.access$4(UnifiedSWTSwingApplication.java:1) at com.windriver.ide.application.UnifiedSWTSwingApplication.start(UnifiedSWTSwingApplication.java:37) at org.eclipse.pde.internal.junit.runtime.UITestApplication.start(UITestApplication.java:52) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:146) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:356) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:171) 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:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:476) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:416) at org.eclipse.equinox.launcher.Main.run(Main.java:1141) at org.eclipse.equinox.launcher.Main.main(Main.java:1116)
Uwe - shouldn't this particular one be resolved with your SafeTreeViewer contribution?
No. SystemView, line 3244 is calling a method of the tree widget directly, so SafeTreeViewer cannot kick in.
Seen similar exceptions during workbench shutdown from smartRefresh() ... getViewAdapter() ... getInputProvider() ... SystemView#getShell() See backtrace below. I was tempted to just fix the getShell() call, since we should get rid of passing the shell around anyways. But seeing that there are other exceptions in smartRefresh() during shutdown as well, I think we should try and avoid any SystemView refreshes when the Workbench is already shutting down. It might help to register as a SaveParticipant, so we know we're already shutting down. The issue is not severe, but since lots of people have been seeing these exceptions during workbench shutdown, it's a must-fix for 2.0.1 Exceptions: Caused by: org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:3563) at org.eclipse.swt.SWT.error(SWT.java:3481) at org.eclipse.swt.SWT.error(SWT.java:3452) at org.eclipse.swt.widgets.Widget.error(Widget.java:432) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:325) at org.eclipse.swt.widgets.Control.getShell(Control.java:1366) at org.eclipse.rse.internal.ui.view.SystemView.getShell(SystemView.java:1149) at org.eclipse.rse.internal.ui.view.SystemView.getInputProvider(SystemView.java:625) at org.eclipse.rse.internal.ui.view.SystemView.getViewAdapter(SystemView.java:1328) at org.eclipse.rse.internal.ui.view.SystemView.smartRefresh(SystemView.java:3518) at org.eclipse.rse.internal.ui.view.SystemView$ResourceChangedJob.runInUIThread(SystemView.java:2005) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:94) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) Unhandled event loop exception during blocked modal context. org.eclipse.swt.SWTException: Failed to execute runnable (org.eclipse.swt.SWTException: Widget is disposed) at org.eclipse.swt.SWT.error(SWT.java:3563) at org.eclipse.swt.SWT.error(SWT.java:3481) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:126) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3659) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3296) at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:158) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:326) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:495) at org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog.run(ProgressMonitorJobsDialog.java:268) at org.eclipse.ui.internal.ide.application.IDEWorkbenchAdvisor.disconnectFromWorkspace(IDEWorkbenchAdvisor.java:396) at org.eclipse.ui.internal.ide.application.IDEWorkbenchAdvisor.postShutdown(IDEWorkbenchAdvisor.java:313) at org.eclipse.ui.internal.Workbench.shutdown(Workbench.java:2702)
Created attachment 78233 [details] Patch to suppress "widget is disposed" during shutdown Attached patch suppresses the "widget is disposed" exceptions when a refresh is requested while the tree is already disposed. It's not a perfect safeguard though. Expanding a large remote file tree on a slow connection, and quitting eclipse immediately after, leads to 5-10 exceptions being printed due to IllegalState of bundles resolved -- I dont't think we can really fix this, but the patch should alleviate the problem for the most common cases.
Dave can you review this?
Okay, this is much better than printing exceptions.
Patch applied.
