Bug 174408 - Deadlock opening document
Deadlock opening document
Status: RESOLVED FIXED
Product: editor
Classification: Unclassified
Component: -- Other --
6.x
All All
: P1 (vote)
: 6.x
Assigned To: Vitezslav Stejskal
issues@editor
: THREAD
: 174475 174528 174555 174564 174575 174618 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-13 03:31 UTC by _ tboudreau
Modified: 2009-10-20 13:43 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
thread dump (31.16 KB, text/plain)
2009-10-13 03:31 UTC, _ tboudreau
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2009-10-13 03:31:20 UTC
Seems 100% reproducible.  Open javacard.project.  Run Find Usages on, for example, AIDPanel.  Double click a usage from
another form (may be reproducible with any Java source;  reproduced it twice with forms).  IDE deadlocks.

See attached thread dump - classic deadlock:
 - Editor initialization thread is inside a CloneableEditor.DoInitialize, waiting for the AWT tree lock (it is
constructing a JEditorPane on the wrong thread)
 - AWT thread is holding the AWT tree lock and waiting for the CloneableEditor.DoInitialize to complete
Comment 1 _ tboudreau 2009-10-13 03:31:46 UTC
Created attachment 89349 [details]
thread dump
Comment 2 _ tboudreau 2009-10-13 03:39:12 UTC
Also happens if you right-click any form and choose Edit.  Workaround:  Open the form editor first, then switch to the
source tab.

My guess is this is caused by a different initialization sequence when the source editor appears inside a multiview.
Comment 3 David Strupl 2009-10-13 09:04:03 UTC
Marek, can you please have a look?
Comment 4 mslama 2009-10-13 10:03:15 UTC
NbEditorKit.call should not access AWT hierarchy because it is called outside AWT. Passing to Vita.
Comment 5 Vitezslav Stejskal 2009-10-13 16:43:14 UTC
Trying to fix...
Comment 6 Vitezslav Stejskal 2009-10-13 17:47:21 UTC
local changeset: d29a273d9541
Comment 7 mslama 2009-10-14 12:06:57 UTC
*** Issue 174528 has been marked as a duplicate of this issue. ***
Comment 8 Vitezslav Stejskal 2009-10-14 12:47:17 UTC
The fix is now in http://hg.netbeans.org/jet-main/rev/d29a273d9541, which is a child of 6ebeddb99737, which introduced
the problem. Therefore d29a273d9541 can be directly applied to team repositories simply by:

hg fetch -r d29a273d9541 http://hg.netbeans.org/jet-main
Comment 9 Vitezslav Stejskal 2009-10-14 12:51:20 UTC
*** Issue 174475 has been marked as a duplicate of this issue. ***
Comment 10 David Strupl 2009-10-14 12:51:28 UTC
*** Issue 174475 has been marked as a duplicate of this issue. ***
Comment 11 Vitezslav Stejskal 2009-10-14 15:01:00 UTC
*** Issue 174555 has been marked as a duplicate of this issue. ***
Comment 12 mslama 2009-10-14 17:24:13 UTC
*** Issue 174564 has been marked as a duplicate of this issue. ***
Comment 13 _ tboudreau 2009-10-14 19:09:35 UTC
The fix looks ok for a hotfix, but:
1. The JEditorPane subclass does not need to be an anoymous inner class with a reference to the NbEditorKit that created it, it can be a nested class (also 
preferable for debugging things as it is easier to find in source).  Same for the BaseTextUI subclass - neither one needs a reference to the instance that 
created them, so they should not be inner classes at all.
2.  The JEditorPane is still constructed on a background thread.  Having updateUI() be a pseudo-no-op *probably* fixes the problem of the tree lock being 
taken inside its constructor, but it does not guarantee it - anyone implementing AWT and Swing (Apple, Classpath, whoever) could easily run some code that 
does take the tree lock in some superclass constructor.  If there is really no choice except to create the JEditorPane in a background thread, that is a design 
bug that needs to be fixed.

Reopening as P4 w/ changed summary, pending a more maintainable fix.
Comment 14 Vitezslav Stejskal 2009-10-15 09:44:10 UTC
Tim, in this case I prefer to have this report closed with the original summary, etc. There are many duplicates and more
are still coming. It's confusing to duplicate them to an issue that apparently has nothing to do with the problem.
Please open a new issue if you still feel like doing so. Back to you questions:

ad #1 - I'm sorry, but I don't understand. What is the difference between 'inner class' and 'nested class'. Anyway, are
you saying that I should have created 'private static final class J extend JEditorPane ...' and the same for the BaseTextUI?

ad #2 - You are right. This was done solely to make the slowness detector happy, ie. to pre-load classes related to
highlighting layers *outside* of AWT. So, yes, it is a design bug - how do you preload swing classes outside of AWT?
Comment 15 Quality Engineering 2009-10-15 10:24:34 UTC
Integrated into 'main-golden', will be available in build *200910150201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/d29a273d9541
User: Vita Stejskal <vstejskal@netbeans.org>
Log: #174408: using fake BaseTextUI to prevent AWTTreeLock access
Comment 16 Vitezslav Stejskal 2009-10-15 11:02:50 UTC
*** Issue 174618 has been marked as a duplicate of this issue. ***
Comment 17 _ tboudreau 2009-10-15 16:50:22 UTC
ad#1 
> Anyway, are you saying that I should have created 'private static final class J extend JEditorPane ...' and the same for the BaseTextUI?

Yes.  Inner classes are more expensive.

ad#2
Not pretty, but I did something like this in the new mobility project wizard to bring project creation time down to an acceptable level.  ClassPreloader.start() 
is triggered in a static block when the first mobility project wizard panel is created;  ClassPreloader.stop() is called when the code that actually needs the 
classes starts to run:
http://hg.netbeans.org/main/file/b52384bf425b/mobility.project/src/org/netbeans/modules/mobility/project/ui/wizard/ClassPreloader.java

If it's just classloading that is causing your problem, this can help.  On the other hand, maintaining the list of classes is not fun.
Comment 18 _ tboudreau 2009-10-15 17:28:06 UTC
I've created issue 174683 to track the component creation problem.
Comment 19 Vitezslav Stejskal 2009-10-19 09:42:13 UTC
ad#1 - Ok, I'll do that.
ad#2 - Thanks for the advice, but I'm not going to do this. If anything like that is needed in Netbeans then we should
have some general policy/recommendation how to do things like this. I don't want to do this adhoc. Plus, I think my
situation is a little bit more complicated, because of the use of Lookup - I don't know all the classes that I might
find in the Lookup when looking up for example HighlightingsLayerFactory. But I don't think this is really that much of
a problem.
Comment 20 David Strupl 2009-10-20 13:43:52 UTC
*** Issue 174575 has been marked as a duplicate of this issue. ***


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