Bug 80028 - CloneableEditorSupport and Multiview Deadlock
CloneableEditorSupport and Multiview Deadlock
Status: RESOLVED DUPLICATE of bug 75596
Product: editor
Classification: Unclassified
Component: -- Other --
5.x
Other All
: P2 (vote)
: 6.x
Assigned To: issues@editor
issues@editor
OSLO
: THREAD
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-11 22:16 UTC by jlam
Modified: 2007-11-05 13:44 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Deadlock Thread Dump (16.50 KB, text/plain)
2006-07-11 22:17 UTC, jlam
Details
After the first deadlock I restarted and tried switching views again. Once I click on the tab, everything freezes. (34.12 KB, text/plain)
2006-07-11 22:28 UTC, jlam
Details

Note You need to log in before you can comment on or make changes to this bug.
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 ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo