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.
The deadlock occured when I disabled reloadable java module; attaching thread dump. Although I tried hard, I could not find who holds openide.nodes.Children.MUTEX, which seems to stop FolderRecognizer and then most of other threads.
Created attachment 6743 [details] Thread dump
LookNode in OpenIDE-request-processor-0 holds the MUTEX: it queries for shortDescription which goes through naming to folderList (imho OK) and waits for it (OK) FolderList (in "Folder recognizer") recognizes some BrokenDataShadow, calls infamous DO.setValid(false) which tries to destroy its Node trying to enter the MUTEX and never finish.
I don't think so. Each LookNode instance has its own mutex. FilterNode.destroy run in FolderRecognizer uses Children.MUTEX - a different instance. Correct ?
Correct, the deadlock is a bit lower, there are two Mutexes: at o.o.util.Mutex.readAccess(Mutex.java:172) inststance LookNode.MUTEX at o.n.api.looks.LookNode.getShortDescription(LookNode.java:412) at o.o.nodes.FilterNode.changeOriginal(FilterNode.java:257) Ch.MUTEX changeOriginal uses Mutex.Privileged, 4 lines above 257 is: Children.PR.enterWriteAccess(); which means ORP-0 holds write access to Children.MUTEX, the rest is the same. But you've alerted me with tha fact that *each* LookNode has its own Mutex, the worst thing I've ever heard about Looks. Looks were meant to be memory friendly but each Mutex consists of 6 objects, costing it total 160Bytes. Moreover, naming an instance field "MUTEX" is not much readable.
Either looks or nodes --> changing to looks for now.
added keyword PROJECTS, because we need to distinguish issues against NB4.0 and S1Sx.y
*** This issue has been marked as a duplicate of 30907 ***
verified - it's duplicate.