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: | CloneableEditorSupport and Multiview Deadlock | ||
---|---|---|---|
Product: | editor | Reporter: | jlam <jlam> |
Component: | -- Other -- | Assignee: | issues@editor <issues> |
Status: | RESOLVED DUPLICATE | ||
Severity: | blocker | CC: | mkleint, mmirilovic, pnejedly |
Priority: | P2 | Keywords: | THREAD |
Version: | 5.x | ||
Hardware: | Other | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Deadlock Thread Dump
After the first deadlock I restarted and tried switching views again. Once I click on the tab, everything freezes. |
Description
jlam
2006-07-11 22:16:13 UTC
Created attachment 31743 [details]
Deadlock Thread Dump
Created attachment 31745 [details]
After the first deadlock I restarted and tried switching views again. Once I click on the tab, everything freezes.
In the second dump, the HackMap calls unfriendly foreign code under a lock. In the first dump, I don't like the rave/insync behaviour. To the concern about insync: What do you have in mind? Insync retrieves EditorCookie, calls openDocument on it. All done in AWT thread, as expected by the API. There doesn't seem to be done anything illegal from insync point of view. It just calls the public API, whihc doesn't specify any restrictions (beside the AWT domain AFAIK, which is satisfied). Sorry, I was wrong. The insync is just loading the document, as expected (lazily, after the switch to proper view, if I understand it correctly). The problematic part there is multiview, which requests element creation under its own lock. The document loading thread runs into the lock later so it can't proceed loading. Note that even if the document was loaded synchronously (as opposed to loading in separate thread) from openDocumentImpl/DOCUMENT_NO, this deadlock could still happen if some other thread requested the document asynchronously in between. possibly a duplicate of #75596 should be fixed in trunk. the listening on toolbar visibility changes now invokeLaters to prevent the deadlock. So I tentatively closing as dup of issue 75596. Please reopen if the problem reappears. *** This issue has been marked as a duplicate of 75596 *** |