| Summary: | Deadlock during CVS decoration | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Philipe Mulet <philippe_mulet> | ||||
| Component: | Team | Assignee: | Michael Valenta <Michael.Valenta> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | critical | ||||||
| Priority: | P1 | CC: | harald, jasc | ||||
| Version: | 2.0 | ||||||
| Target Milestone: | 2.1 RC2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 2000 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Philipe Mulet
Got deadlocked while updating CVS decorators after performing a replace with repository latest contents. See stack trace below. It happened to me quite a few times. Created attachment 3711 [details]
Deadlock thread dump
"ModalContext" acquired workspace lock, then tries to get CVS lock, while "Decoration" thread did acquire the CVS lock first, then starves waiting to acquire the workspace lock. Is this happening on a project that is in dev.eclipse.org (i.e. given a project, we could try to reproduce)? Having said that, we know what solution is needed but we're not sure why it's happening in the first place so it would be helpful if we could reproduce it. *** This bug has been marked as a duplicate of 31530 *** I was playing with a local repository in our lab, replacing 5 significant projects at once in a quite old workspace (not 2.0.2, but somewhere in between 2.0 and 2.1). Also, an antivirus was in the middle of scanning my machine, thus considerably slowing down my machine, and interestingly quite a number of deadlocks became visible (also see bug 33231, bug 32905). I don't think this is a duplicate of bug 31530, which exhibits an issue in between CVS lock and the JavaModel lock. This one scenario is a problem in between the workspace lock and CVS lock. I think the significant factor here is the workspace. You say it was 2.1 but old. There was a bug related to phantom folders some time ago in 2.1 that would have left the workspace in a state that would result in the behavior that is causing the deadlock. I'll try to determine which build the bug was in so we can try to reproduce (unless you happen to remember what the build was). Turing off decorators and performing a Team/Update on all the projects involved should fix the problem (i.e. you should then be able to turn decorators back on without any problems). The fix for this bug will be to ensure that the CVS decorator does not update the workspace in any way. *** Bug 31530 has been marked as a duplicate of this bug. *** Well for bug 31530, we (JDT/Core) had some responsibility, independantly from the fact that the decoration thread was causing trouble. The JavaModel shouldn't cause any such deadlock involving its internal cache lock, we think this is now resolved (also see bug 33231). From your end, it actually feels the same issue though. Fix has been released to HEAD |