QBuild stopper because this deadlock can be reproduced in every time.

Please attach full thread dump. Thanks.

Created attachment 22690 [details]
treads dump

IMO the problem is not in the MUTEX. The problem (probably) is that:
1. ProjectManager.findProject is called for a directory, so it sets
LOADING_PROJECT into dir2Proj and starts to load the project.
2. During loading of the project (after some listeners), the
ProjectManager.findProject is called (for the same directory, I suppose) again.
The ProjectManager detects that the project is being loaded and waits until it
is loaded (dir2Proj.wait()). Obviously noone can call notify in this case.

Is this known to be reproducible?

There are three problems I can see here. I will reassign this bug for one of
them (the one I think is *probably* easiest to fix and would help the most) but
file related bug reports for the other things. Currently I am not sure whether
such a deadlock could occur for other project types, but I don't see anything
unusual that apisupport/project is doing that would make it responsible - it is
just calling unremarkable Filesystems API methods from within the project
constructor, as surely other project types do.

1. (This bug report, now) Within the body of any listener callback - in this
case, FilesystemHandler.fileFolderCreated - it is forbidden to acquire new locks
or call into foreign code which might acquire new locks. cvslite is permitted to
refresh internal caches based on info available purely from the Filesystems API,
I think, but it may not call SharabilityQuery from within the body of the
callback. Perhaps it could

1a. Handle the folder creation event asynchronously, in case the cache does not
have to updated immediately for the rest of the filesystem to behave correctly.

1b. Update the cache with simple info about the new folder, but not update
sharability / ignorability info now - fill in that field in the cache lazily, if
and when it is needed for something, e.g. HTML badging of the folder icon, or
CVS operations like "Add (Recursively)". (Calling SQ.gS in the event callback,
even if it returned normally with no deadlock or exception, would be useless
here: the correct return value is only known by the project type, which is not
going to be ready to answer until *after* its constructor has finished.)

2. Trying to call ProjectManager.findProject within the body of another call to
PM.fP (that is actually constructing a project) is never going to work. But it
ought to be throwing an IllegalStateException, which would be ugly but
recoverable, rather than just deadlocking. There is already code to handle this
case but apparently it did not work. Issue #60073.

3. The Filesystems API is apparently firing a folder creation event for a folder
which already existed, which is incorrect. (Though if that were fixed, there
might still be a problem if cvslite tried to ask SharabilityQuery for info on it
right away, since the project is still being created on disk at this point!)
Issue #60074.

I am able to reproduce it with my userdir. With empty userdir it works correctly. 

I am able to reproduce this with cvslite+apisupport/project. I was not able to
reproduce it with J2SE project (but this does not mean apisupport/project does
something wrong).

Moved event handling to separate thread using RP. RP aquires locks too but
hopefuly won't deadlock with projects.
To test, build AU module of javacvs/cvsmodule from the "ea5_au2_patches" branch.

/cvs/javacvs/cvsmodule/src/org/netbeans/modules/versioning/system/cvss/FilesystemHandler.java,v
 <--  FilesystemHandler.java
new revision: 1.3.2.1; previous revision: 1.3

Please, can you verify this issue?

Verify in trunk please.

verified