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.
Summary: | Deadlock between JavaFastOpen$Evaluator and AntProjectHelper$something | ||
---|---|---|---|
Product: | java | Reporter: | Antonin Nebuzelsky <anebuzelsky> |
Component: | Classpath | Assignee: | Tomas Zezula <tzezula> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | jglick, pnejedly, tzezula |
Priority: | P2 | Keywords: | THREAD |
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Thread Dump |
Description
Antonin Nebuzelsky
2005-07-14 13:10:29 UTC
Created attachment 23100 [details]
Thread Dump
it looks like a java module problem It seems that the netbeans project type registers the classpaths into GPR under the project mutex. Looks to be bug in GPR to me. It is receiving a property change event and illegally attempts to acquire a nonprivate monitor within the body of the callback. In the GPR I don't see a nice way how to solve this issue. The GlobalPathRegistry.getSourceRoots has to be synchronized since it calculates the cached values which are reset in the GPR.resetSourceRootsCache (also needs to be synchronized). The GPR.getSourceRoots() calls SFBQ.findSourceRoots and the ProjectizedSFBQ tries to acquire the ProjectManager.mutex. Removing the SFBQ.findSOurceRoos from the synchronized block may cause race condition. Another solution is to order the way how the locks are acquired, in this case the GPR.getSourceRoots will need to acquire the ProjectManager.mutex before entering the synchronized block, but the java API does not depend on the projects API. So if the locks cannot be ordered, then getSourceRoots must not be synchronized over its whole body. It can synchronize on this only when actually reading or writing the sourceRoots field, but not when calculating a new value for it. I.e. synch (this) { if (sR != null) return sR; } _sR = calcSR(); synch (this) { return sR = _sR; } It may then happen that >1 thread is running calcSR() at once, and the "losers" will have their final result clobbered, but that is not a real problem. Checking in api/src/org/netbeans/api/java/classpath/GlobalPathRegistry.java; /cvs/java/api/src/org/netbeans/api/java/classpath/GlobalPathRegistry.java,v <-- GlobalPathRegistry.java new revision: 1.15; previous revision: 1.14 done Checking in api/test/unit/src/org/netbeans/api/java/classpath/GlobalPathRegistryTest.java; /cvs/java/api/test/unit/src/org/netbeans/api/java/classpath/GlobalPathRegistryTest.java,v <-- GlobalPathRegistryTest.java new revision: 1.7; previous revision: 1.6 done Verified. --- NetBeans IDE Dev (Build 070214) 1.6.0; Java HotSpot(TM) Server VM 1.6.0-b105 Linux version 2.6.12-1.1390_FC4smp running on i386 en_US (nb); UTF-8 |