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.

Bug 80028

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
While running our pack and switching in multiview from one tab to another, I hit
the following deadlock.  It looks like the two locks are coming from
CloneableEditorSupport and Multiview.
Comment 1 jlam 2006-07-11 22:17:02 UTC
Created attachment 31743 [details]
Deadlock Thread Dump
Comment 2 jlam 2006-07-11 22:28:34 UTC
Created attachment 31745 [details]
After the first deadlock I restarted and tried switching views again.  Once I click on the tab, everything freezes.
Comment 3 Petr Nejedly 2006-07-12 15:20:47 UTC
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.
Comment 4 Peter Zavadsky 2006-08-02 21:00:01 UTC
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).
Comment 5 Petr Nejedly 2006-08-03 08:42:53 UTC
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.
Comment 6 Milos Kleint 2006-08-11 08:36:01 UTC
possibly a duplicate of #75596
should be fixed in trunk. the listening on toolbar visibility changes now
invokeLaters to prevent the deadlock.
Comment 7 Miloslav Metelka 2006-08-11 13:21:32 UTC
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 ***