Community
Participate
Working Groups
Build Identifier: Eclipse 3.5.1 In our scenario a dead lock with DeltaProcessor.resourceChanged occurs (see attached stack trace). Thread Worker-0 owns the OrderedLock and calls JavaProject.resolveClasspath. Our class path container (RequiredDcsClasspathContainer) waits for a lock (DevConf Lock). Thread ModalContext owns WorkspaceRoot and DevConf Lok and waits for OrderedLock. => Dead Lock I think it is problematic to call client code (class path container) when holding OrderedLock. Reproducible: Sometimes
Created attachment 162031 [details] Stack Trace
see similar deadlocks Bug 291764, Bug 292404
The DeltaProcessor#resourceChanged (and eventually IClasspathContainer#getClasspathEntries) is running inside the notification thread and other threads are not allowed to modify the workspace during the resource change event. JDT/Core needs to resolve the classpath container during this event. Just wondering, in the other thread, can't you check if the workspace tree is locked or not and proceed with the modify operation?
(In reply to comment #3) > The DeltaProcessor#resourceChanged (and eventually > IClasspathContainer#getClasspathEntries) is running inside the notification > thread and other threads are not allowed to modify the workspace during the > resource change event. JDT/Core needs to resolve the classpath container during > this event. Just wondering, in the other thread, can't you check if the > workspace tree is locked or not and proceed with the modify operation? This would mean I would have to release DevConf Lock in ModalContext if the tree is locked. This would be somehow strange for me to release a lock that was aquired some stack frames above. I think the root cause of the issue is calling client code inside OrderedLock. Any client code using locks might get this problem. Would it be possible to perform the work of DeltaProcessingState.resourceChanged in a separate Job to get out of the OrderedLock issue?
Just for clarification: DevConf lock protects read and write access of our data structure. The only thing we could do in our class path container is to check if the tree is locked and then not to aquire our lock and not to return our class path. But I think this would be no good solution.
(In reply to comment #4) > I think the root cause of the issue is calling client code inside OrderedLock. > Any client code using locks might get this problem. > Would it be possible to perform the work of > DeltaProcessingState.resourceChanged in a separate Job to get out of the > OrderedLock issue? Well, I did think about that. But that would be a significant change. I will investigate, though.
Dani, This fix might require moving all the code that reacts to a resource change and a subsequent classpath resolution be moved to a separate job to avoid the deadlock. At this stage such a change might pose considerable risks. What is your opinion?
(In reply to comment #7) > Dani, > > This fix might require moving all the code that reacts to a resource change and > a subsequent classpath resolution be moved to a separate job to avoid the > deadlock. At this stage such a change might pose considerable risks. > > What is your opinion? Such a change is definitely out of scope for 3.6 and we'd first have to investigate and understand that this is the right solution.
Also note that it's possible to resolve the issue on the client side (Bug 291764, Bug 292404).
Hi Dani, I do not know how I should fix this. ModalContext already has /R and our lock that protects our data structure (DevConf). Access to a resource causes ModalContext to wait for OrderedLock: ModalContext has /R has DevConf Lock waits for OrderedLock Thread Worker-0 is broadcasting changes. JDT calls our class path container (CPC). Our CPC has 2 options to avoid the dead lock: 1. Access our data structure without DevConf lock. This would introduce a race condition. 2. Return an empty classpath. This would break our clients. Worker 0 has OrderedLock waits for DevConf Lock Our component itself is a big framework with lots of tools on top. Again I think it is very problematic that JDT calls client code while owning the OrderedLock.
I didn't look deeply into how you could fix this but given the other similar cases could get fixed on the client side I'd assume it's possible here as well. >Again I think it is very problematic that JDT calls client code while owning >the OrderedLock We do this for a long time now. I don't say it's perfect but definitely not something we are going to change so late in the 3.6 cycle.
We should be able to fix this in core.resources - it shouldn't hold the ws lock while firing the resource delta.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
