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 when changing properties of freeform project | ||
---|---|---|---|
Product: | projects | Reporter: | Milan Kubec <mkubec> |
Component: | Ant | Assignee: | David Konecny <dkonecny> |
Status: | CLOSED FIXED | ||
Severity: | blocker | Keywords: | THREAD |
Priority: | P1 | ||
Version: | 4.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 42682 | ||
Attachments: | thread dumps |
Description
Milan Kubec
2004-10-13 12:29:51 UTC
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. |