Description Stefan Xenos 2015-10-09 21:23:33 EDT

This is really the same as bug 178875, which is still not fixed.

There is a period during workbench start up where the workbench is not yet able to honor its API contracts (specifically, until the Workbench.init() call has run to completion). The workbench must not invoke any asyncExecs until this has happened, since an asyncExec is allowed to use the workbench's public APIs which won't work at that time.

For example, calling PlatformUI.getWorkbench().getAdapter(ICommandService.class) before initialization will throw an exception... and an exception during plugin activation will often prevent Eclipse from starting.

Currently, the workbench seems to trigger these unsafe asyncExecs in two places: the event loop is pumped "for free" by the call to Display.setSynchronizer (bug 479435) and the second is around line 2955 of Workbench.java, which looks like this: 

				while (true) {
					if (!display.readAndDispatch()) {
						if (initDone)
							break;
						display.sleep();
					}
				}

As long as this remains the case, the Workbench is likely to crash on startup any time a plugin runs an asyncExec in its plugin startup code. 

Note: there is no way to make syncExecs completely safe. If they're deferred until after startup, we risk deadlock. If they're not, we risk a crash to desktop. We can make asyncExec completely safe but should also make a best effort not to make syncExec any worse than it is now.