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 in ProjectManager | ||
|---|---|---|---|
| Product: | projects | Reporter: | Martin Krauskopf <mkrauskopf> |
| Component: | Generic Infrastructure | Assignee: | Milos Kleint <mkleint> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | anebuzelsky, issues, issues, mmirilovic |
| Priority: | P1 | Keywords: | RANDOM, THREAD |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
deadlock.txt
deadlock.txt with read access second patch |
||
Created attachment 48000 [details]
deadlock.txt
done. The problem was: When Thread1 started loading projectA, it sets the loadingThread variable to Thread1. Any thread attempting to load projectA now stops and waits for the load to finish. However if Thread2 attempts to read projectB now, it resets loadingThread to Thread2 and if that happens before Thread1 gets into the wrong code that calls findProject(), the exception is not thrown and the Thread1 deadlocks. Checking in ProjectManager.java; /cvs/projects/projectapi/src/org/netbeans/api/project/ProjectManager.java,v <-- ProjectManager.java new revision: 1.34; previous revision: 1.33 Checking in ProjectManager.java; /cvs/projects/projectapi/src/org/netbeans/api/project/ProjectManager.java,v <-- ProjectManager.java new revision: 1.33.2.1; previous revision: 1.33 don Fresh trunk build from this morning (CET), hours or two old. Reproduced again. Again the similar problem without exception. This time with read access only. Attaching thread dump. The fix was not sufficient, so reopening this one. I can file a new one if you want. Created attachment 48231 [details]
deadlock.txt with read access
Created attachment 48262 [details]
second patch
The following scenario was not covered by previous fix: ProjectA gets created, in createProject() calls findProject() on projectB and then findProject() on itself (projectA). Now we keep a list of project folder FileObjects that are procesed by current thread. See patch. Again may be slightly clearer to @Override initialValue() -> new HashSet<FileObject>(). No, please. You'd trade one/two conditions for a whole class, that's unnecessary waste. If it is dangerous to fixthis, I would vote for removing previously applied patch from the beta1 branch. The only steps/trigger which reproduced/caused this so far was usage of VisibilityQuery in the Rails project. The VisibilityQuery is not and will not be used in the beta1 branch. For now we have used workaround in Rails project. So maybe this could be waived. Checking in ProjectManager.java; /cvs/projects/projectapi/src/org/netbeans/api/project/ProjectManager.java,v <-- ProjectManager.java new revision: 1.33.2.2; previous revision: 1.33.2.1 done |
See the attached thread dump. The "wizard-descriptor-asynchronous-jobs" waits - dir2Proj.wait(); while holding write access to ProjectManager's mutex. But notification is not reached - nobody can reach the dir2Proj.notifyAll() since ProjectManager's mutex is needed, but is held (in write access) by the waiting thread (??) Not sure what role has "Versioning" thread which is also trying to gain ProjectManager's mutex. I supposed it's OK to call VisibilityQuery from within ProjectManager's write access.... actually now I see there, in the ProjectManager, code: if (Thread.currentThread() == loadingThread) { throw new IllegalStateException("Attempt to call ProjectManager.findProject within the body of \ ProjectFactory.loadProject (hint: try using ProjectManager.mutex().postWriteRequest(...) \ within the body of your Project's constructor to prevent this)"); // NOI18N } but it was not thrown...