Bugzilla – Full Text Bug Listing
| Summary: | Deadlock creating new project in CDTCommonProjectWizard (1.30) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | James Blackburn <jamesblackburn+eclipse> | ||||
| Component: | cdt-core | Assignee: | Project Inbox <cdt-core-inbox> | ||||
| Status: | RESOLVED DUPLICATE | QA Contact: | Doug Schaefer <cdtdoug> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | ||||||
| Version: | 7.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux-GTK | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
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. 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 *** 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. |
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.