Created attachment 16934 [details]
Deadlock

Honzi, thanks for your exhaustive and comprehensive report :). But I
don't see any deadlock.
I only see, that all thread dumps shows the same thing: Scanning Queue
is  blocked by same native method:
"Scanning Queue" daemon prio=2 tid=0x0eed1db0 nid=0xd54 runnable
[f63f000..f63fd8c]
        at java.io.WinNTFileSystem.getBooleanAttributes(Native Method)
        at java.io.File.exists(File.java:680)
        at
org.netbeans.modules.masterfs.SpecialDelegates.checkValidWindowsDrive(SpecialDelegates.java:146)

Radku, can you evaluate it? Thanks

I think I know where the problem is. I am working on it. Radku, please
ignore this.

So, I debugged this on Jan's computer and found out the problem is
that the URL of a classpath root provided from classpath is:
"jar:file:/c:/j2sdk1.4.2_03/lib/tools.jar!/"
while URL provided from the filesystem on a given root fileobject is:
"jar:file:/C:/j2sdk1.4.2_03/lib/tools.jar!/"
So, these URLs are not equal, thus scanning gets into an endless loop
trying to resolve the root provided by the classpath. I talked to
Tomas Zezula and he knows how to fixe it. Since this needs to be fixed
in classpath implementation, I am reassigning it to him.

To Trung: this is not a threading issue - it is not a deadlock but
rather an endless loop caused by different URLs returned for the same
file on Windows. On Jan's computer it happens deterministically. It is
because how his JDK_HOME variable is set (since classpath seems to
create URL pointing to JDK from this environment variable). I don't
know what the THREAD keyword means, but are you sure it is appropriate
for this issue?

Checking in
project/src/org/netbeans/modules/apisupport/project/ClassPathProviderImpl.java;
/cvs/apisupport/project/src/org/netbeans/modules/apisupport/project/ClassPathProviderImpl.java,v
 <--  ClassPathProviderImpl.java
new revision: 1.35; previous revision: 1.34
done

*** Issue 49256 has been marked as a duplicate of this issue. ***

presumably fixed, no way how to verify, closing.