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: | Deadlock opening document | ||
|---|---|---|---|
| Product: | editor | Reporter: | _ tboudreau <tboudreau> |
| Component: | -- Other -- | Assignee: | Vitezslav Stejskal <vstejskal> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | jglick, mslama |
| Priority: | P1 | Keywords: | THREAD |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: | thread dump | ||
|
Description
_ tboudreau
2009-10-13 03:31:20 UTC
Created attachment 89349 [details]
thread dump
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. Marek, can you please have a look? NbEditorKit.call should not access AWT hierarchy because it is called outside AWT. Passing to Vita. Trying to fix... local changeset: d29a273d9541 *** Issue 174528 has been marked as a duplicate of this issue. *** 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 *** Issue 174475 has been marked as a duplicate of this issue. *** *** Issue 174475 has been marked as a duplicate of this issue. *** *** Issue 174555 has been marked as a duplicate of this issue. *** *** Issue 174564 has been marked as a duplicate of this issue. *** 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. 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? 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 *** Issue 174618 has been marked as a duplicate of this issue. *** 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. I've created issue 174683 to track the component creation problem. 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. *** Issue 174575 has been marked as a duplicate of this issue. *** |