Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 31530

Summary:

deadlock with CVS decorators during workbench startup or when switching to Java Perspective

Product:

[Eclipse Project] Platform

Reporter:

Harald Niesche <harald>

Component:

Team

Assignee:

Michael Valenta <Michael.Valenta>

Status:

RESOLVED DUPLICATE

QA Contact:

Severity:

critical

Priority:

CC:

jasc, mlq.eclipse, philippe_mulet

Version:

2.1

Target Milestone:

2.1 RC2

Hardware:

OS:

Windows 2000

Whiteboard:

Attachments:

Description	Flags
Stack of Eclipse in deadlock	none

Description Harald Niesche

2003-02-11 06:55:30 EST

This problem occurs with the I20030129 and M5 builds.

From my posts to eclipse.tools:

I have ~13 projects in my workspace, 2 of them closed (I couldn't reproduce
the problem having them open, but I'm not sure if this means anything).

In "Preferences | Workbench | Label Decorations" I have turned on all
options. I currently reproduce the problem with the workbench starting in
the Resource Perspective by switch to the Java perspective after it has
started up. It happened originally after I had done several things to my
configuration and simply tried to start eclipse. There are no messages in
workspace/.metadata/.log when this happens during startup.

The main thread is inside JavaElement.getElementInfo() (line 296() holding
the monitor on the JavaModelManager and trying to acquire the workspace
lock, while the Decoration thread tries to enter the synchronized method
JavaModelManager.getPerProjectInfo() (line 926) while holding the workspace
lock (acquired from CVSLightweightDecorator.isDirty() using
EclipseFolder.run()).

One question that comes to mind is why the call to isDirty triggers a build 
(shouldn't it just return true or false instead of actually compiling?).

I can reproduce the bug in I20030129 and M5, the workspace that I use to 
reproduce is large and contains several projects I can't share freely. But I'll 
keep it in order to verify any fixes. (Is there anything else I could provide, 
apart from trying to reproduce with open source projects?)

Comment 1 Harald Niesche

2003-02-11 07:05:03 EST

Created attachment 3400 [details]
Stack of Eclipse in deadlock

This is a stacktrace obtained from the Eclipse debugger.

In the "Threads and Monitors" view I can see that main is holding the monitor
of the JavaModelManager and Decoration is "in contention".

I could also provide the workspace .log if that helps (although nothing that
seems related is apparent).

Comment 2 Michael Valenta

2003-02-11 10:47:12 EST

This is a classic deadlock case where two threads compete for the same locks 
but acquire them in a different order. The CVS decorator acquires the 
workspace lock because of the same type of deadlock ordering between the 
workspace lock and the CVS synchronizer lock (see bug 29212). 

There are really two issues here. One is that JDT is open to deadlock because 
they use two locks and do not gaurantee that they are always acquired in the 
same order. As bug 29212 points out, this is really a bigger issue that needs 
to be addressed at some point. 

The other issue is that the CVS decorator acquires the workspace lock but 
really shouldn't need to. The case where the CVS decorator can cause a 
workspace operation involves a deleted file that has not been committed and 
the first-time reading of the sync info from disk for the parent folder. CVS 
sync info is stored as a session property on resources that exist but as Core 
sync info on non-existant resources. Hence, when the sync info is read from 
disk, the sync info for the phantom representing the deleted file is set to 
the sync info on disk. The problem is that setting the Core sync info requires 
the workspace lock. To ensure that dealock would never occur, the workspace 
lock had to be acquired first (i.e. the best ordering to prevent deadlock was 
to always acquire the workspace lock before acquiring the CVS lock).

However, since the phantom sync info is persisted accross platform 
invocations, setting it when the sync info is read is a redundant operation. 
In fact, a check has since been added to avoid setting the sync info of the 
phantom if the new info is the same as the old. I can't think of any other 
case where the isDirty check performed by the decorator would cause a 
workspace operation. The problem is that if one did, then dealock could occur. 
If the isDirty check were performed outside a workpspace runnable, some 
mechanism would need be be added to ensure that no workspace operations were 
performed.

Comment 3 Jean-Michel Lemieux

2003-02-26 10:39:19 EST

*** Bug 33243 has been marked as a duplicate of this bug. ***

Comment 4 Michael Valenta

2003-03-03 12:21:03 EST

Marking a dupe of 33243. The traces differ but the solution is the same.

*** This bug has been marked as a duplicate of 33243 ***

Comment 5 Philipe Mulet

2003-03-04 06:06:40 EST

Note that in latest integration build (as of today) we will no longer execute 
client code inside the JavaModel lock as exhibited here. This is only meant to 
be an internal cache synchronization lock. 

This being said, the decoration thread still seems to be doing too much in its 
own thread, but the JavaModel shouldn't cause a deadlock any longer.