Bug 153767

Created attachment 74079 [details]
thread dump while IDE is frozen

Please evaluate. Thanks.

update: deleting the var directory doesn't fix the problem anymore, so now I can't start NB at all.

Can someone help me, how can I make NB forget what projects were open?

gekkothelizard, have profiled any of your projects?

mkubec, the deadlock is coming from 
org.netbeans.modules.projectapi.AuxiliaryConfigImpl.getConfigurationFragment(AuxiliaryConfigImpl.java:78)

look at the locked AWT thread...

"AWT-EventQueue-1" prio=6 tid=0x03e04400 nid=0xda0 in Object.wait() [0x2f19d000..0x2f19fb14]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x047e8d58> (a org.openide.util.Mutex$QueueCell)
	at java.lang.Object.wait(Object.java:485)
	at org.openide.util.Mutex$QueueCell.sleep(Mutex.java:1602)
	- locked <0x047e8d58> (a org.openide.util.Mutex$QueueCell)
	at org.openide.util.Mutex.enterImpl(Mutex.java:723)
	at org.openide.util.Mutex.enter(Mutex.java:630)
	at org.openide.util.Mutex.readEnter(Mutex.java:613)
	at org.openide.util.Mutex.readAccess(Mutex.java:282)
	at org.netbeans.modules.projectapi.AuxiliaryConfigImpl.getConfigurationFragment(AuxiliaryConfigImpl.java:78)
	at
org.netbeans.modules.profiler.nbmodule.NbModuleProjectTypeProfiler.isProfilingSupported(NbModuleProjectTypeProfiler.java:117)

No I've never used the profiler. I've seen some profiler related files in one of our projects at the company, so maybe 
someone was fiddling with and committed the files to svn, but it's not likely that project was open.

Also after figured out how to make NB forget about the opened projects I started working with them again. I got a 
deadlock once while updating one of the from svn, but a restart solved that, and no I experienced no freezing 
afterwards.

The problem is not in AWT-EventQueue-1, but in org.netbeans.modules.j2ee.clientproject.classpath.ClassPathProviderImpl
which calls project code under private lock.

Note: this particular class org.netbeans.modules.j2ee.clientproject.classpath.ClassPathProviderImpl has been moved to
java.api.common module (see changeset 17231ac7a6df)

David, any suggestion on this one?

Tomas,

this deadlock is in org.netbeans.modules.j2ee.clientproject.classpath.ClassPathProviderImpl which was replaced with very
identical org.netbeans.modules.java.api.common.classpath.ClassPathProviderImpl so basically the problem exists in
several other project types including J2SE. Deadlock is between:
* a thread calling ClassPathProviderImpl.findClassPath which in turn calls synchronized getCompileTimeClasspath; and
* a thread which hold Project write lock and modifies a properties which results in evaluator calling propertyChange on
ClassPathProviderImpl which is synchronized
How do you think this should be resolved? AppClientProject$ProjectOpenedHookImpl.projectOpened could acquire Project
read access before calling ClassPathProviderImpl but that would be just workaround and problem would raise again
somewhere else. Better fix is to use different lock object in ClassPathProviderImpl for modifying dirCache.

David, you're right that J2SE project had the same problem - see issue 149267.
Since the j2ee.clientproject and java.j2seproject have been refactored to use the same ClassPathProviderImpl class from
the java.api.common module (the fix is there), the deadlock is inheritedly fixed in main (not in 6.5, though) already.
In 6.5, java.j2seproject and j2ee.clientproject had their own version (similar) of ClassPathProviderImpl.