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: | Hang/deadlock on opening project | ||
|---|---|---|---|
| Product: | projects | Reporter: | _ tboudreau <tboudreau> |
| Component: | Generic Infrastructure | Assignee: | Petr Hrebejk <phrebejk> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | Keywords: | THREAD |
| Priority: | P1 | ||
| Version: | 4.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
stack trace
Proposed fix |
||
|
Description
_ tboudreau
2005-04-10 18:04:21 UTC
Created attachment 21522 [details]
stack trace
This appears after the fix of issue #57352. Since it was merged into 4.1 branch, the deadlock can occur in 4.1 as well. Evaluating whether there is some other solution then rollback the fix of issue #57352. It's a mess. 100% reproducible on my mac. From the stack trace, looks as if you could invokeLater org.netbeans.modules.vcscore.actions.GeneralCommandAction.enable(GeneralCommandAction.java:139) and it would probably get it out of the way of other locks. IMHO it's not a fault of VCS. In AWT thread projects are calling foreign code under a lock, which seems to cause the deadlock. Moving to projects. Tim, I see. There are more points which could resolve the deadlock (do not synchronize instace creation in FolderInstance and do not fire change events from lookup when someone is doing a query). But the deadlock can occur in other ways if only some branches are eliminated. The real cause is IMHO calling an unknown code under the lock. OpenProjectList should not use special synchronization, it should be using ProjectManager.mutex. CloseProject.refresh should be rescheduled to EQ, I guess. OpenProjectList should use extreme caution when calling foreign code (CES.open) while holding a lock. Created attachment 21569 [details]
Proposed fix
OK. Fixed in 4.2. Tim please verify > OpenProjectList should not use special synchronization, it should be using > ProjectManager.mutex. There is no reason for that. OPL only needs to keep it's internal data. Why to lock on some global mutex. > CloseProject.refresh should be rescheduled to EQ, I guess. Should not be necessary now. > OpenProjectList should use extreme caution when calling foreign code > (CES.open) while holding a lock. It does. Better said it did before someone else added the calls to external code into synchroinized block. Btw. you should check where you are adding notifyOpened() calls as well. I fixed those in OPL.open(). But the one in the OPL constructor still causes that some people get NULL from OpenProjects.getDefault() Checking in src/org/netbeans/modules/project/ui/OpenProjectList.java; /cvs/projects/projectui/src/org/netbeans/modules/project/ui/OpenProjectList.java,v <-- OpenProjectList.java new revision: 1.31; previous revision: 1.30 done Fixed in 4.1 Checking in src/org/netbeans/modules/project/ui/OpenProjectList.java; /cvs/projects/projectui/src/org/netbeans/modules/project/ui/OpenProjectList.java,v <-- OpenProjectList.java new revision: 1.30.4.1; previous revision: 1.30 done |