Bugzilla – Full Text Bug Listing
| Summary: | Deadlock adding breakpoint | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Marco Hunsicker <eclipse> |
| Component: | Debug | Assignee: | JDT-Debug-Inbox <jdt-debug-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse, jamesblackburn+eclipse, Michael_Rennie, pawel.1.piech |
| Version: | 3.6.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Marco Hunsicker
Breakpoint listeners should never try to modify breakpoints inside a listener call, they should schedule a job instead. I've seen dozens of such deadlocks. For platform I wonder if we could create some kind of an assertion to detect this pattern. (In reply to comment #0) > used). I assume that this behavior causes the workspace lock to be acquired > instead of using the same resource as the current process? This is correct, the marker rule locks the whole workspace. I suppose marker modifications happen rarely enough and are quick enough that the resource system folks didn't feel the need to invest in a more granular locking mechanism. (In reply to comment #1) > Breakpoint listeners should never try to modify breakpoints inside a listener > call, they should schedule a job instead. I've seen dozens of such deadlocks. The action happens inside an editor save action right before or during debugging. I've already changed the code to be run inside a workspace job and awaiting customer response whether this indeed fixes the problem. > For platform I wonder if we could create some kind of an assertion to detect > this pattern. Now, that I know this limitation I can deal with it. Better documentation could help here. An assertion would certainly be good if possible. > (In reply to comment #0) > > used). I assume that this behavior causes the workspace lock to be acquired > > instead of using the same resource as the current process? > > This is correct, the marker rule locks the whole workspace. I suppose marker > modifications happen rarely enough and are quick enough that the resource > system folks didn't feel the need to invest in a more granular locking > mechanism. The behavior somewhat contradicts the API. There is the specific IResourceRuleFactory#markerRule(IResource). I was quite surprised to learn that this creates a workspace lock. In org.eclipse.core.internal.resources.Rules there is a comment that says that the "team hook currently cannot change this rule". Maybe it is already planned for a future version to expand here. It would certainly be welcomed. Anyway, thanks very much for your quick action. Much appreciated. From the backtraces, it's not clear who holds the WS lock. The WS (which is different to WS root rule) is held when modifying the workspace. No rules are held when modifying markers - both rule factories return null for marker modification. Can you attach a full backtrace of the threads involved when Eclipse locks up? If there's a resource change notification caused by the save, in progress then this could very well be: bug 249951 Since the reported issue is with changing markers / resources while saving is occurring, it sounds more likely this is dupe of bug 249951. I will close this as a dupe until the reporter provides the requested stack dumps (and they prove otherwise). *** This bug has been marked as a duplicate of bug 249951 *** |