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.

Bug 60976 - Deadlock between JavaFastOpen$Evaluator and AntProjectHelper$something
Summary: Deadlock between JavaFastOpen$Evaluator and AntProjectHelper$something
Status: VERIFIED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Classpath (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: Tomas Zezula
URL:
Keywords: THREAD
Depends on:
Blocks:
 
Reported: 2005-07-14 13:10 UTC by Antonin Nebuzelsky
Modified: 2007-02-14 14:34 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Thread Dump (14.00 KB, text/plain)
2005-07-14 13:11 UTC, Antonin Nebuzelsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Antonin Nebuzelsky 2005-07-14 13:10:29 UTC
See the attached thread dump.

(1) Thread AntProjectHelper.RP is holding a mutex for read access and is waiting
for GlobalPathRegistry lock.

(2) Thread Default RequestProcessor (JavaFastOpen$Evaluator) is on the other
hand holding the GlobalPathRegistry lock and is waiting to enter the mutex for
privileged access. The result is a nice deadlock.
Comment 1 Antonin Nebuzelsky 2005-07-14 13:11:55 UTC
Created attachment 23100 [details]
Thread Dump
Comment 2 Martin Roskanin 2005-08-31 14:27:56 UTC
it looks like a java module problem
Comment 3 Tomas Zezula 2005-08-31 15:41:35 UTC
It seems that the netbeans project type registers the classpaths into GPR under
the project mutex.
Comment 4 Jesse Glick 2005-08-31 16:24:09 UTC
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.
Comment 5 Tomas Zezula 2005-09-12 17:20:56 UTC
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.
Comment 6 Jesse Glick 2005-09-12 23:36:40 UTC
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.
Comment 7 Tomas Zezula 2005-09-13 13:59:33 UTC
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
Comment 8 Max Sauer 2007-02-14 14:34:42 UTC
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