Bug 153767 - Netbeans freezing completely on startup
Netbeans freezing completely on startup
Status: RESOLVED FIXED
Product: javaee
Classification: Unclassified
Component: App Client
6.x
PC Windows XP
: P2 (vote)
: 6.x
Assigned To: Dongmei Cao
issues@javaee
: THREAD
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-24 13:35 UTC by gekkothelizard
Modified: 2009-02-19 20:58 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
thread dump while IDE is frozen (41.23 KB, text/plain)
2008-11-24 13:36 UTC, gekkothelizard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description gekkothelizard 2008-11-24 13:35:50 UTC
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.
Comment 1 gekkothelizard 2008-11-24 13:36:41 UTC
Created attachment 74079 [details]
thread dump while IDE is frozen
Comment 2 Milan Kubec 2008-11-24 13:54:55 UTC
Please evaluate. Thanks.
Comment 3 gekkothelizard 2008-11-24 14:42:24 UTC
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?
Comment 4 Lukas Hasik 2008-11-24 16:58:53 UTC
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)
Comment 5 gekkothelizard 2008-11-24 18:13:24 UTC
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.
Comment 6 Milan Kubec 2008-11-25 08:51:09 UTC
The problem is not in AWT-EventQueue-1, but in org.netbeans.modules.j2ee.clientproject.classpath.ClassPathProviderImpl
which calls project code under private lock.
Comment 7 Dongmei Cao 2008-12-03 00:58:11 UTC
Note: this particular class org.netbeans.modules.j2ee.clientproject.classpath.ClassPathProviderImpl has been moved to
java.api.common module (see changeset 17231ac7a6df)
Comment 8 Dongmei Cao 2008-12-03 01:03:58 UTC
David, any suggestion on this one?
Comment 9 David Konecny 2008-12-03 01:43:44 UTC
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.
Comment 10 Dongmei Cao 2008-12-03 22:16:14 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo