Bug 95048 - [Progress][Dialogs] Widget Is Disposed error after retrieving updates
Summary: [Progress][Dialogs] Widget Is Disposed error after retrieving updates
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.1   Edit
Hardware: PC All
: P2 major (vote)
Target Milestone: 3.1 M7   Edit
Assignee: Tod Creasey CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 95123 (view as bug list)
Depends on: 91791
Blocks:
  Show dependency tree
 
Reported: 2005-05-12 16:49 EDT by Grant Gayed CLA
Modified: 2005-05-13 16:16 EDT (History)
5 users (show)

See Also:


Attachments
Patch (813 bytes, patch)
2005-05-13 09:55 EDT, Tod Creasey CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Grant Gayed CLA 2005-05-12 16:49:22 EDT
3.1M7 0512 noon build
- observed on win32, motif and gtk

- invoke Help->Software Updates->Find and Install...
- select "Search for new features to install", Next
- select "eclipse.org update site", Finish
- select "VE", "EMF SDK 2.0.1" and "GEF 3.0.1->Graphical Editing Framework SDK 
3.0.1", next
- accept the agreements, Next
- Finish
- press Install All, and following will be written to .log:

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:393)
	at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:295)
	at org.eclipse.swt.widgets.Control.getMonitor(Control.java:928)
	at org.eclipse.jface.window.Window.getInitialLocation(Window.java:550)
	at org.eclipse.jface.window.Window.initializeBounds(Window.java:745)
	at org.eclipse.jface.dialogs.Dialog.initializeBounds(Dialog.java:643)
	at org.eclipse.jface.window.Window.create(Window.java:422)
	at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:996)
	at org.eclipse.jface.window.Window.open(Window.java:770)
	at org.eclipse.jface.dialogs.ProgressMonitorDialog.open
(ProgressMonitorDialog.java:603)
	at org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog$4.run
(ProgressMonitorJobsDialog.java:339)
	at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:147)
	at org.eclipse.ui.internal.UISynchronizer.syncExec
(UISynchronizer.java:28)
	at org.eclipse.swt.widgets.Display.syncExec(Display.java:3226)
	at 
org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog$3.openDialog
(ProgressMonitorJobsDialog.java:327)
	at 
org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog$3.checkTicking
(ProgressMonitorJobsDialog.java:316)
	at 
org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog$3.internalWorked
(ProgressMonitorJobsDialog.java:361)
	at org.eclipse.jface.operation.AccumulatingProgressMonitor$Collector.run
(AccumulatingProgressMonitor.java:96)
	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:2878)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2537)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.block
(ModalContext.java:153)
	at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:303)
	at org.eclipse.jface.dialogs.ProgressMonitorDialog.run
(ProgressMonitorDialog.java:447)
	at org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog.run
(ProgressMonitorJobsDialog.java:261)
	at org.eclipse.ui.internal.progress.ProgressManager$3.run
(ProgressManager.java:861)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69)
	at org.eclipse.ui.internal.progress.ProgressManager.busyCursorWhile
(ProgressManager.java:895)
	at org.eclipse.ui.internal.progress.ProgressManager.busyCursorWhile
(ProgressManager.java:871)
	at org.eclipse.update.internal.ui.wizards.InstallWizard2$1.run
(InstallWizard2.java:428)
	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:2878)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2537)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1601)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1565)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench
(Workbench.java:315)
	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:230)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run
(EclipseStarter.java:345)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run
(EclipseStarter.java:158)
	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:324)
	at org.eclipse.core.launcher.Main.invokeFramework(Main.java:328)
	at org.eclipse.core.launcher.Main.basicRun(Main.java:272)
	at org.eclipse.core.launcher.Main.run(Main.java:974)
	at org.eclipse.core.launcher.Main.main(Main.java:950)
Comment 1 Grant Gayed CLA 2005-05-12 17:36:33 EDT
SN says:

"The problem is that SWT is accepting a disposed parent shell, creating the 
child shell and failing later.  On Motif, it exits.

MVM, I think we need to fix this for M7.  We are considering adding the code 
that checks for a disposed parent but this will only make the failure happen 
consistently (correctly) on all platforms when the shell is created.  Any idea 
who this belongs to?  We should consider either not making our fix for M7 or 
making it after the real problem of the disposed parent is fixed."
Comment 2 Tod Creasey CLA 2005-05-13 09:13:38 EDT
Given that M7 is today we should look to do this for RC1. 

The problem is this line

final ProgressMonitorJobsDialog dialog = new ProgressMonitorJobsDialog(
                ProgressManagerUtil.getDefaultParent());

because we grab the parent at the time of creation. Because of the API lockdown
we  didn't switch to using the new IShellProvider but given this is an issue we
should look into using the shell provider from Progress.

Adding Stefan as he is the architect of the IShellProvider idea. 

We should consider solving the issue in Bug 91791 and using it here.

Stefan what did you and Jim decide on?
Comment 3 Steve Northover CLA 2005-05-13 09:42:33 EDT
Would testing for a disposed parent and using null instead be an easy and safe 
enough fix given that the operation eventually fails a bit later when you pass 
in a disposed parent?
Comment 4 Tod Creasey CLA 2005-05-13 09:54:54 EDT
Having talked to Steve having general protection against disposed parents is
worthwhile. This solution will solve all cases - even those that do not use the
shell provider.

The API change is a better way of doing this but this specific problem can be
fixed without it.
Comment 5 Tod Creasey CLA 2005-05-13 09:55:17 EDT
Created attachment 21100 [details]
Patch
Comment 6 Tod Creasey CLA 2005-05-13 10:35:13 EDT
This was found due to Bug 95116
Comment 7 Tod Creasey CLA 2005-05-13 11:10:56 EDT
Fixed in build >20050512
Comment 8 Tod Creasey CLA 2005-05-13 11:13:45 EDT
*** Bug 95123 has been marked as a duplicate of this bug. ***
Comment 9 Tod Creasey CLA 2005-05-13 16:16:36 EDT
Verified in 20050513-1400