Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 321696 - Deadlock creating new project in CDTCommonProjectWizard (1.30)
Summary: Deadlock creating new project in CDTCommonProjectWizard (1.30)
Status: RESOLVED DUPLICATE of bug 321640
Alias: None
Product: CDT
Classification: Tools
Component: cdt-core (show other bugs)
Version: 7.0   Edit
Hardware: PC Linux-GTK
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Doug Schaefer CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-04 07:10 EDT by James Blackburn CLA
Modified: 2010-08-06 13:06 EDT (History)
0 users

See Also:

Attachments
backtrace (20.00 KB, text/plain)
2010-08-04 07:10 EDT, James Blackburn CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description James Blackburn CLA 2010-08-04 07:10:53 EDT 
Created attachment 175827 [details]
backtrace

Just had this backtrace from a user where Eclipse seemed to lock up during project creation.  Not quite sure what's up yet.
Comment 1 James Blackburn CLA 2010-08-06 12:43:30 EDT 
Trawled the Heap. The DeadlockDetector (LockManager.locks) has failed and been null'd. The result is that this odd CDT flow has deadlocked as the Rule held by the ModalContext isn't correctly transferred to main as part of the syncExec.
Comment 2 James Blackburn CLA 2010-08-06 12:55:15 EDT 
The root cause is the .log entry in bug 321640.

It's possible that job cancellation can easily break the deadlock detector e.g. bug 321751, or it could have been broken because of bug 316839, or some other as yet undiscovered bug.

*** This bug has been marked as a duplicate of bug 321640 ***
Comment 3 James Blackburn CLA 2010-08-06 13:06:16 EDT 
And for posterity's sake, if the Deadlock detector is present, you get this:

CDTCommonProjectWizard$1$1.run() line: 266	
UILockListener.doPendingWork() line: 164	
UISynchronizer$3.run() line: 158	
RunnableLock.run() line: 35	
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 134	

If it's not, you get this:

CDTCommonProjectWizard$1$1.run(CDTCommonProjectWizard.java:266)
RunnableLock.run(RunnableLock.java:35)                                  
Synchronizer.runAsyncMessages(Synchronizer.java:134)

Without the UILockListener there's no 'currentWork' to use when working out if the lock can be handed immediately to the UI thread.