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.

Bug 131060 - Deadlock when editing simple html
Summary: Deadlock when editing simple html
Status: VERIFIED FIXED
Alias: None
Product: web
Classification: Unclassified
Component: HTML Editor (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: Marek Fukala
URL:
Keywords:
: 130917 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-03-25 15:59 UTC by Jaromir Uhrik
Modified: 2009-05-18 10:47 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Full thread dump attached... (19.06 KB, text/plain)
2008-03-25 16:02 UTC, Jaromir Uhrik
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaromir Uhrik 2008-03-25 15:59:57 UTC
Product Version: NetBeans IDE Dev (Build 200803250006)
Java: 1.6.0_10-beta; Java HotSpot(TM) Client VM 11.0-b11
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)

It is reproducible according to the following steps:
1.Start IDE with clear userdir and create j2se project
2.Create new html file from the template
3.Write to the 'body' section <ul></ul>
4.Write to this 'ul' section <li></li> (use the completion for writing this list tag)
5.Repeat step 4 and the IDE goes to freeze
Comment 1 Jaromir Uhrik 2008-03-25 16:02:00 UTC
Created attachment 59037 [details]
Full thread dump attached...
Comment 2 Marek Fukala 2008-03-25 16:51:09 UTC
The problem is that I am touching GSF parser in the html bracket matching implementation. This breaks the rule - lock
source first then the document. The braces matching always calls by matcher from document.render() which in fact
prevents me from using the parser functionality.

        at org.netbeans.modules.gsf.SourceAdapter.runUserActionTask(SourceAdapter.java:71)
        at org.netbeans.modules.html.editor.HTMLBracesMatching.findMatches(HTMLBracesMatching.java:164)
        at org.netbeans.modules.editor.bracesmatching.MasterMatcher$Result.run(MasterMatcher.java:533)
        at org.netbeans.editor.BaseDocument.render(BaseDocument.java:1206)
        at org.netbeans.modules.editor.bracesmatching.MasterMatcher$Result.run(MasterMatcher.java:486)

I'll do a dirty hack now in the html completion item - I'll check the document for being readlocked before entering the
Reformat.lock() which locks the source.

However the final solution IMHO should be not to call the braces matcher implementation under the document readlock. 
Comment 3 Marek Fukala 2008-03-25 16:52:46 UTC
*** Issue 130917 has been marked as a duplicate of this issue. ***
Comment 4 Marek Fukala 2008-03-26 16:25:01 UTC
fixed in changeset 335604c91a07.

The fix is kind of hacky since I explicitly test if the source lock is locked before running the source task.

The proper fix IMHO is to either not to call the braces matchers under document readlock or use the push model instead
of pull one for providing the matches by the braces matchers. Both needs to be done on editor side.
Comment 5 Vitezslav Stejskal 2008-03-27 12:57:56 UTC
I filed issue #131284.
Comment 6 Jaromir Uhrik 2008-04-01 11:19:51 UTC
Verified. I cannot reproduce now with the reported use-case in the following build:
Product Version: NetBeans IDE Dev (Build 200804010004)
Java: 1.6.0_10-beta; Java HotSpot(TM) Client VM 11.0-b11
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)