Bug 118763 - Deadlock when displaying a dialog immediately after startup
Deadlock when displaying a dialog immediately after startup
Status: RESOLVED FIXED
Product: editor
Classification: Unclassified
Component: Settings
6.x
All All
: P2 (vote)
: 6.x
Assigned To: Vitezslav Stejskal
issues@editor
: RANDOM, THREAD
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-12 21:54 UTC by Andrei Badea
Modified: 2007-11-05 13:42 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Thread dump (20.04 KB, text/plain)
2007-10-12 21:55 UTC, Andrei Badea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrei Badea 2007-10-12 21:54:27 UTC
I got the attached deadlock when expanding the Databases node, right-clicking a connection and choosing Connect. The DB
Explorer doesn't seem to be the culprit though.
Comment 1 Andrei Badea 2007-10-12 21:55:24 UTC
Created attachment 50865 [details]
Thread dump
Comment 2 Petr Jiricka 2007-10-13 08:51:15 UTC
Andrei, so who do you think is the culprit?
Comment 3 David Konecny 2007-10-15 08:44:18 UTC
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();
Comment 4 Vitezslav Stejskal 2007-10-15 09:18:37 UTC
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.
Comment 5 David Konecny 2007-10-15 09:38:27 UTC
Re. "BaseOptions and MacrosMIMEOptionFile" - yeah, that piece looked a bit suspicious too.

Re. "JEditorPane.createEditorKitForContentType("text/x-jsp")" - thanks, I will fix that.
Comment 6 Vitezslav Stejskal 2007-10-15 10:51:56 UTC
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


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