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 when displaying a dialog immediately after startup | ||
|---|---|---|---|
| Product: | editor | Reporter: | Andrei Badea <abadea> |
| Component: | Settings | Assignee: | Vitezslav Stejskal <vstejskal> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | dkonecny, pjiricka |
| Priority: | P2 | Keywords: | RANDOM, THREAD |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: | Thread dump | ||
|
Description
Andrei Badea
2007-10-12 21:54:27 UTC
Created attachment 50865 [details]
Thread dump
Andrei, so who do you think is the culprit? It is question on editor: can BaseKit.getActions() be called from AWT thread? can it be called from non-AWT thread? do
you have any recommendations? Please comment and pass back to me.
In JspEditorWarmUpTask code it looks like we intentionally calling jspKit.getActions() in AWT thread (but for example
JavaEditorWarmUpTask does not). jspKit.getActions() call is synchronized on Settings.class. Down the stack trace
AWT thread is waiting for org.netbeans.modules.editor.java.JavaDocument which is being initialized in different thread
(org.netbeans.modules.java.editor.JavaEditorWarmUpTask.run(JavaEditorWarmUpTask.java:194)) and which is blocked via
FixLineSyntaxState.fixSyntaxStateInfos(FixLineSyntaxState.java:355) which cannot progress because it needs to
synchronize on Settings.class.
The simple fix (in line with JavaEditorWarmUpTask) would be to init kit actions outside of AWT thread, that is moving
out of AWT these lines:
// Init of JSPKit and JSPOptions
jspKit = JEditorPane.createEditorKitForContentType("text/x-jsp"); //NOI18N
//creating actions instances
jspKit.getActions();
I don't think JspEditorWarmUpTask is doing something wrong. The problem is somewhere between BaseOptions and
MacrosMIMEOptionFile. The OptionsInitializer calls BaseOptions to load the settings and then is supposed to initialize
the map in its updateSettingsMap, but BaseOptions and MacrosMIMEOptionFile sets the settings directly by
Settings.setValue, which in turn fires events from inside the code protected by Settings.class lock. That's wrong I
think and we will have to fix it.
Btw, you should not be using JEditorPane.createEditorKitForContentType("text/x-jsp") for find the kit for you mime type.
Use CloneableEditorSupport.getEditorKit("text/x-jsp") instead. For detailed explanation please read
http://editor.netbeans.org/doc/editor-kit-registry.html and issue #57994.
Re. "BaseOptions and MacrosMIMEOptionFile" - yeah, that piece looked a bit suspicious too.
Re. "JEditorPane.createEditorKitForContentType("text/x-jsp")" - thanks, I will fix that.
Settings should not fire events when initializing settings maps. Checking in editor/libsrc/org/netbeans/editor/Settings.java; /cvs/editor/libsrc/org/netbeans/editor/Settings.java,v <-- Settings.java new revision: 1.74; previous revision: 1.73 done Checking in editor/lib/test/unit/src/org/netbeans/editor/SettingsTest.java; /cvs/editor/lib/test/unit/src/org/netbeans/editor/SettingsTest.java,v <-- SettingsTest.java new revision: 1.4; previous revision: 1.3 done |