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.
[200410121800, JDK 1.5.0_01] Reproducible deadlock. Create freeform project but don't set any source folder in the wizard. After the project is created open its properties and add source folder and close project properties. See attached file - first three dumps are from first occurence of the problem and other three deadlocks are from reproduction.
Created attachment 18253 [details] thread dumps
I think freeform.ui.View$RootChildren.updateKeys cannot call C.K.sK synchronously; it has to use RequestProcessor or something.
*** Issue 50355 has been marked as a duplicate of this issue. ***
The problem is in FreeformSources.initSources() and its ProjectManager.mutex().postWriteRequest() call. There are two threads: EQ and RP. The FreeformSources.initSources() is called in RP, but EQ already is in ProjectManager.mutex().readAccess(). That means that ProjectManager.mutex().postWriteRequest() call in FreeformSources.initSources() is blocking. Before change in ProjectsRootNode$ProjectChildren.stateChanged (issue 50529) there was only one thread and therefore ProjectManager.mutex().postWriteRequest() was non-blocking. The simplest fix could be to not call ProjectManager.mutex().postWriteRequest() from FreeformSources.initSources() but post that to some other RP to make it always non-blocking.
I still disagree and think that making FreeformSources behave asynchronously, and thus unpredictably, would be bad; and that the bug here (at least what I can see from the last thread dump) is in View$RootChildren.updateKeys: while being called from foreign code which may be holding a lock, you may not acquire a new lock, and currently C.K.sK acquires a lock and thus may not be called synch from a callback. The first thread dump seems to be something quite different - a lock conflict between FreeformSources used as a monitor, and PM.mutex. That appears to a totally different bug. fireChange is right to lock *something* to make sure it has a consistent list of listeners, but not FS.this, used for other purposes. It (and a/rCL) should probably lock on 'listeners', not 'this'. There are a lot of thread dumps in here, I did not analyze every one, but you can see what I am getting at. In general, I do *not* want to introduce new calls to RequestProcessor (asynchrony) in critical logic methods without a very good reason. It hurts testability, produces random bugs, and will often lead to other (harder) deadlocks anyway.
"View$RootChildren.updateKeys: while being called from foreign code which may be holding a lock, you may not acquire a new lock, and currently C.K.sK acquires a lock and thus may not be called synch from a callback." - after thinking about this thrice I now believe that you are right and that this is real cause. Also I reproduced isssue 50355 and got different tread dump so I will reopen that issue and fix it differently.
When children change is triggered by XML change then I made it asynchronous. In other cases (addNotify()) I left it as it was. Fixed in: src/org/netbeans/modules/ant/freeform/ui/View.java; new revision: 1.10; previous revision: 1.9 test/unit/src/org/netbeans/modules/ant/freeform/ui/ViewTest.java; new revision: 1.2; previous revision: 1.1
David, would you, please, merge the fix into branch QBE200410121800 as well? Thanks
Integrated to Q-build branch: src/org/netbeans/modules/ant/freeform/ui/View.java; new revision: 1.9.6.1; previous revision: 1.9 test/unit/src/org/netbeans/modules/ant/freeform/ui/ViewTest.java; new revision: 1.1.12.1; previous revision: 1.1
*** Issue 50704 has been marked as a duplicate of this issue. ***
Verified in dev-200410241800.
Issue #58491 is similar.