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 207855 - Deadlock in ClassIndexManager$InternalLock vs. PM.mutex
Summary: Deadlock in ClassIndexManager$InternalLock vs. PM.mutex
Status: RESOLVED FIXED
Alias: None
Product: editor
Classification: Unclassified
Component: Parsing & Indexing (show other bugs)
Version: 7.2
Hardware: PC Linux
: P3 normal (vote)
Assignee: Tomas Zezula
URL:
Keywords: THREAD
Depends on: 208434
Blocks:
  Show dependency tree
 
Reported: 2012-01-27 19:15 UTC by Jesse Glick
Modified: 2012-02-15 16:34 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Thread dump (41.11 KB, text/plain)
2012-01-27 19:15 UTC, Jesse Glick 		Details
Firing changes asynchronously from CacheFolder. (3.93 KB, patch)
2012-01-30 13:48 UTC, Jan Lahoda 		Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2012-01-27 19:15:35 UTC 
Created attachment 115333 [details]
Thread dump

Opening a number of projects in a dev build. Lots of code potentially contributing, but the actual lock conflict is:

"main-class-updater" daemon prio=10 tid=0xf1814800 nid=0xff9 in Object.wait() [0xeef62000]
...
	at org.openide.util.Mutex.readAccess(Mutex.java:327)
...
	at org.netbeans.api.project.FileOwnerQuery.getOwner(FileOwnerQuery.java:104)
...
	at org.netbeans.modules.java.source.usages.ClassIndexManager.getUsagesQuery(ClassIndexManager.java:124)
	- locked <0x9eac6640> (a org.netbeans.modules.java.source.usages.ClassIndexManager$InternalLock)
...

"Opening projects" daemon prio=10 tid=0xf3f62000 nid=0xfc7 waiting for monitor entry [0xf3278000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.netbeans.modules.java.source.usages.ClassIndexManager.getUsagesQuery(ClassIndexManager.java:103)
	- waiting to lock <0x9eac6640> (a org.netbeans.modules.java.source.usages.ClassIndexManager$InternalLock)
	at org.netbeans.modules.java.source.indexing.JavaIndex.hasSourceCache(JavaIndex.java:245)
...
Comment 1 Jan Lahoda 2012-01-30 13:47:09 UTC 
The easiest way to break the deadlock would be to fire events asynchronously from CacheFolder. No real API from filesystems for that, but I will attach a patch that works.

Anyway, seems really strange that Maven listens on caches in private parts of the userdir - why? Seems like a possible performance problem to inspect each and every file changed event, regardless if it happens in parts of the disk maintained by the maven support or not. Moreover, it may not even be necessary - please check the Maven support whether it still needs that.
Comment 2 Jan Lahoda 2012-01-30 13:48:17 UTC 
Created attachment 115389 [details]
Firing changes asynchronously from CacheFolder.
Comment 3 Tomas Zezula 2012-01-30 16:15:14 UTC 
Also the APH fires under project's write lock:
	at org.netbeans.spi.project.support.ant.ProjectProperties$PP$2.run(ProjectProperties.java:345)
	at org.openide.util.Mutex.readAccess(Mutex.java:288)
	at org.netbeans.spi.project.support.ant.ProjectProperties$PP.fireChange(ProjectProperties.java:353)
	at org.netbeans.spi.project.support.ant.ProjectProperties$PP.put(ProjectProperties.java:222)
	at org.netbeans.spi.project.support.ant.ProjectProperties.putProperties(ProjectProperties.java:130)
	at org.netbeans.spi.project.support.ant.AntProjectHelper$6.run(AntProjectHelper.java:743)
	at org.netbeans.spi.project.support.ant.AntProjectHelper$6.run(AntProjectHelper.java:741)
	at org.openide.util.Mutex.writeAccess(Mutex.java:397)
	at org.netbeans.spi.project.support.ant.AntProjectHelper.putProperties(AntProjectHelper.java:741)
Comment 4 Tomas Zezula 2012-01-30 18:35:40 UTC 
Fixed jet-main d22660e911c9

Fixed, Jesse please evaluate if firing under PM.mutex.writeAccess is desired.
Comment 5 Jesse Glick 2012-02-14 22:29:47 UTC 
mkleint please check comment #1 and comment #4.
Comment 6 Milos Kleint 2012-02-15 07:16:33 UTC 
I guess the FileUtil.addFileChangeListener(this); method is used to cater to external resource roots. 
If FileUtil.addFileChangeListener(this, __projectRoot__); is used we might get another problem with deep multiproject structures where multiple events will be processed. But I guess that's less of a problem.
the listener will still has to check the project owner, so further problems cannot be entirely avoided, just have it's probability reduced.
Comment 7 Milos Kleint 2012-02-15 07:19:40 UTC 
filed issue 208434 for the filesystem listener problem