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
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)
- locked <0x047e8d58> (a org.openide.util.Mutex$QueueCell)
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
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?
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.