Community
Participate
Working Groups
I20040422 I got into a state where Eclipse appeared to be hung. On further analysis, it was essentially this deadlock: - Thread Worker-1 is doing a resource change notification, so it owns the core workspace lock. It is trying to load classes in JDT core. - Thread Worker-0 is loading a class in JDT core. This calls JDTCore.startup(), which is trying to do a IWorkspace.run This is not actually a deadlock, because the Eclipse class loaders detect this by "timing out" after waiting for another thread to start for more than 5 seconds. However, this time out multiplied by the number of class loads can be quite large, and the result is that Eclipse is hung for several minutes. I will attach the stack traces
Created attachment 9918 [details] Stack traces
Another interesting thing we observed here is that the exact same resource change listener instance is currently processing deltas in both threads. This should be avoided because it leads to this precise race condition (and probably other race conditions). While there is no technical problem with doing this from a core perspective, I think we should fix this in core because it is not something that resource change listener implementors will expect.
Even after fixing this listener problem in core, it is still risky to be doing workspace.run from within JavaCore.startup(). If another thread that owns the workspace lock tries to load classes in JDT core, this same problem will occur. Jerome, is this something that has always been possible, or was it just introduced during the fix to bug 38658? Since this involves resolving classpaths, it also has the side-effect of loading classpath container providers such as PDE during startup.
Yes this is new behavior introduced during the fix to bug 38658. To avoid this we would need some post-startup hook from Platform Core to process the saved state delta.
I will try to process the delta in the indexer thread instead.
Entered bug 59937 against JDT Core.
Released a fix in core.resources to prevent the possibility of resource change notifications happening concurrently (one save participant and one POST_CHANGE event).
