Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 178296

Summary: [Workbench][ErrorHandling] Startup failed due to exception in view creation
Product: [Eclipse Project] Platform Reporter: John Arthorne <john.arthorne>
Component: UIAssignee: Kim Horne <eclipse>
Status: RESOLVED DUPLICATE QA Contact:
Severity: major    
Priority: P3 CC: bokowski, eclipse, mik.kersten, Szymon.Brandys
Version: 3.3   
Target Milestone: 3.3 M7   
Hardware: PC   
OS: Windows Vista   
Whiteboard:
Bug Depends on:    
Bug Blocks: 178330    
Attachments:
Description Flags
Log file none

Description John Arthorne CLA 2007-03-20 11:11:24 EDT 
Build: I20070320-0010

I have Mylar installed.  An exception occurred in a Mylar view on startup, and this caused the workbench to fail to start.  Exceptions in views should not prevent the workbench from starting. I had to delete the Mylar plugins to get the workbench to come up again. Log to follow...
Comment 1 John Arthorne CLA 2007-03-20 11:12:11 EDT 
Created attachment 61402 [details]
Log file
Comment 2 Paul Webster CLA 2007-03-20 12:35:54 EDT 
See bug 178330 ... these could be related.
PW
Comment 3 Tod Creasey CLA 2007-03-20 14:48:29 EDT 
We should definately handle the case where a view fails with at least the error view.
Comment 4 Tod Creasey CLA 2007-03-20 16:10:06 EDT 
John do you have a way to replicate this?
Comment 5 John Arthorne CLA 2007-03-20 17:44:53 EDT 
Kim: possibly related to your startup work
Comment 6 John Arthorne CLA 2007-03-20 18:09:24 EDT 
I don't have an easily reproducible test. Here is what I did:

1) Installed Eclipse+Mylar last week
2) This week replaced my Eclipse with latest build, but kept old version of Mylar
3) The workbench failed to stat.

Perhaps there is some change since last week that causes Mylar to fail to start. I tried a simple test of introducing a runtime exception into some view's createPartControl, and it didn't reproduce the problem.  So, it's not as simple as a failure in a view's startup.  I was hoping the stacks would shed light on what's going on.
Comment 7 Kim Horne CLA 2007-03-21 08:12:45 EDT 
This may indeed be a result of the threading changes.  

We wrapper all part creation in a StartupThreading runnable, allowing parts to be created in the UI thread (as they've always been).  Because the code is being run from the right thread we're then allowing subsequent asyncExecs to be executed in UISynchronizer when they should instead be held until the UI has started.  

I think this is why I favored StartupRunnable being a marker class that was recognized by the UISynchronizer.
Comment 8 Mik Kersten CLA 2007-03-22 17:54:00 EDT 
I assume that this is not reproducible with the M6-based dev builds of Mylar that we started putting out last Wednesday.  Latest is 2.0.0.v20070322-1430 and available from: http://download.eclipse.org/technology/mylar/update-site/dev/e3.3  In the past bugs like this one, where Mylar failed to load, have not caused the workbench to fail to load.  Looks like this bug should stay reproducible with the M5 based build of Mylar, which after April 30th with move to: http://download.eclipse.org/technology/mylar/update-site-archive/2.0M1/e3.3 

Just fyi, the Mylar committers move to the I-builds latest 5 days before the milestone release date (policy is here: http://wiki.eclipse.org/index.php/Mylar_User_Guide#Releases ).  If Platform ever wants a dev build for an I-build sooner than that, or wants us to investigate something like this just let us know via new bug or CC'ing me.  I have a Bugzilla query for all bugs I'm CC'd on, and only found this one by following dependencies.
Comment 9 Kim Horne CLA 2007-05-08 10:39:38 EDT 
This should've been addressed by the fix for bug 178875.  We are now deferring asyncs as we should be.

*** This bug has been marked as a duplicate of bug 178875 ***