This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
A few hours ago I opened some projects in NB (1 ejb, 1 webapp and 1 app client). When I opened one of them (the others where already open) the IDE hung up completely. I restarted it and it did the same thing while opening the projects on startup. After this I shut it down and deleted the var directory. This fixed the problem, but after I restarted the IDE for some reason later it got frozen again on startup. I did a thread dump, hope you can figure out the problem from it.
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.