Bug 66437 - Canceling search leads to broken workspace
Summary: Canceling search leads to broken workspace
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows 2000
: P3 major (vote)
Target Milestone: 3.0 RC2   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-09 18:29 EDT by John Arthorne CLA
Modified: 2004-06-11 10:46 EDT (History)
1 user (show)

See Also:


Attachments
Log file showing trace of cancelation (6.03 KB, text/plain)
2004-06-09 18:29 EDT, John Arthorne CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Arthorne CLA 2004-06-09 18:29:14 EDT
I20040609 1200

1) Switched to the Java perspective and then quickly did Ctrl+Shift+T. 
2) Got a "User operation is blocked dialog". 
3) Clicked the cancel button on the "User Operation" entry in the dialog.
4) The operation canceled as expected.

I am now in a state where all Java tooling is broken. F3 doesn't work, type
hierarchy doesn't work, etc. The Problems view shows no problems in the workspace.

5) Modify a file and hit save (autobuild is on).

Now I get the following problem marker on all projects:

The project was not built since its build path is incomplete. Cannot find the
class file for java.lang.Object. Fix the build path then try building this project.

I had to shutdown, restart, Clean the workspace, and do a full build to get back
into a good state. It seems that JDT isn't recovering from the cancelation of
the build path initialization.

Note: I was testing this scenario heavily in 3.0 RC1 and didn't find any
problems. It seems like there is a recent regression here. CCing Wassim as it
could possibly be caused by the PDE classpath container.
Comment 1 John Arthorne CLA 2004-06-09 18:29:43 EDT
Created attachment 11848 [details]
Log file showing trace of cancelation
Comment 2 Jerome Lanneluc CLA 2004-06-10 09:46:00 EDT
Good find John and thanks for the stack trace. 

Changed JavaModelManager.initializeAllContainers(...) to ensure that the 
containers are not left as 'initialization in progress' if an exception 
traverses this code.
Comment 3 Olivier Thomann CLA 2004-06-11 10:46:40 EDT
Could not reproduce with 200406110010.
Verified in 200406110010