Community
Participate
Working Groups
Build 2.1 RC1 Reopening an old 2.0.2 workspace which was using JRE variable initializer, a deadlock occurred when Java perspective was restoring.
Created attachment 3709 [details] Deadlock thread dump
2 locks involved are: workspace lock and JavaModel info lock. - CVS background decoration is taking workspace lock, and performs some resource modification notified to DeltaProcessor (wondering why it would change any actual resource the delta processor should care about). DeltaProcessor is trying to acquire JavaModel info lock. - Main thread is using populating the JavaModel thus got the info lock, and tries to perform some JRE initialization, which in turn is trying to acquire the workspace lock. -> deadlocked
1. why is deltaprocessor populating the model in reaction to CVS changes ? 2. shouldn't we free the model lock while running JRE initializer ?
VCM plans to fix this particular instance... they believe they should never be modifying the workspace from inside the decorator thread. However, another plugin could easily install a decorator that modifies resources, leaving us open to the same problem. I don't think this problem can be solved by checking if the delta contains only sync info changes (seeing as it was a bug in CVS code that generated this delta, it's not an expected case).
The delta check is just a workaround to prevent an obvious scenario to cause grief. Our code clearly is subject to such deadlocks, if someone performs any multi-threaded action before we have resolved all classpaths. CVS decoration is an example, but I suspect other may find this. Our locked area should never contain any client code, however our lazy initialization story can cause this to occur. I suspect working copy reconciling is another instance where we may be notifying clients (with discovered errors) while we are inside the JavaModel lock (need to double check some more).
We have a regression test for such offending scenario (not released in regular test suites since could be causing major hang). -> ThreadSafetyTests#testDeadlock01()
Also see bug 31530 for similar deadlock due to the JavaModel lock being surfaced to clients (in this scenario, the actual locking is achieved by accessing perProjectInfo which need JavaModel lock too). Per project infos do not need the JavaModel(Manager) lock, they simply need to be synchronized with each other. Should sync on a different object (e.g. per project info table).
PerProjectInfo are now synchronized on their table. Made similar changes onto zipfile cache. Ensure classpath is resolved before opening an element (#getElementInfo), avoiding initializer client code invocation while our lock is taken. Moved working copy problem detection (while reconciliation) outside of the lock as well. There shouldn't be any occurrence of 3rd party code running while we are inside the lock (entered bug 33530 to revisit post 2.1 so as to make the element info creation more optimistic).
Fixed.
*** Bug 31610 has been marked as a duplicate of this bug. ***
Verified.
