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.
Created attachment 108716 [details] thread dump of deadlock Editting, UI hung. Thread dump attached.
Obvios jvi bug, calls userTask under editor write lock.
jVi calls o.n.m.editor.java.JavaKit$JavaInsertBreakAction to insert a new line (as it has since its inception several years ago) and that ends up in the parsing APIs via hints. Reassigning to Java/editor for evaluation, and cc'ing some who are familiar with the JavaKit and Hint code in question. One solution would be to simply return, doing nothing, if the lock is held; in JavaInsertBreakAction or maybe GenerateJavadocAction. FYI, the lock is held by jVi because the user is executing a 'redo' command or a macro. It takes the lock in case an exception occurs, like attempting to modify a guarded section of text, and the entire redo should be rolled back. Now that the platform has undo chunking I'm wondering if that could be part of some scheme so jVi can avoid taking the lock. The semantics of undo chunking nesting presents some problems to work out.
The rule is that caller of runUserTask should not hold the editor lock. It's there from JavaSource -> ParserManager (NB 6.0). The reason is that the task in userTask or parserResultTask needs an access to document. Probably the only possible solution is to disable the hint in this case :-(
IMHO, using of the UndoableEdit chunking mechanism instead of taking the editor lock would be a better solution of the problem. We could simply disable generating of a JavaDoc if the document is already write-locked, however, keep in mind then that user gets different results when a macro is executed and when the macro actions are performed manually step by step.
(In reply to comment #4) > IMHO, using of the UndoableEdit chunking mechanism instead of > taking the editor lock would be a better solution of the problem. Yes, but I think I'll need an API change/addition to get equivalent functionality. Getting this done will take some time. > We could simply disable generating of a JavaDoc if the document is already > write-locked, Better than deadlock. I haven't looked, I'm assuming checking for the "atomicLock" is simple. > however, keep in mind then that user gets different results when > a macro is executed and when the macro actions are performed manually step by > step. Actually, when adding a comment "manually step by step" you do not always get javadoc expansion; for example if scanning is in progress there's no expansion. (at least that's what I've observed) In addition, jVi has some code that detects unexpected changes, generally code completion, and attempts to merge them into its redo buffer; it works ok for simple cases. Not that it really matters in this case, since I doubt it works for comments.
Fixed in jet-main. JavaDoc generating is disabled if the document is already write-locked. http://hg.netbeans.org/jet-main/rev/08ceca4601b0
QE, could you please test the fix? Jan, could you please review the fix? Thanks.
The patch seems fine to me.
Integrated into release701 branch. http://hg.netbeans.org/releases/rev/90c623f3f1ed
Integrated into 'releases' Changeset: http://hg.netbeans.org/releases/rev/90c623f3f1ed User: Dusan Balek <dbalek@netbeans.org> Log: Issue #199156 - deadlock possible if call JavaInsertBreakAction when holding document lock - fixed.
verified Product Version: NetBeans IDE 7.0.1 RC1 (Build 201106222100) Java: 1.7.0; Java HotSpot(TM) Client VM 21.0-b16 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) Userdir: C:\Documents and Settings\tester\.netbeans\7.0.1rc1
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/08ceca4601b0 User: Dusan Balek <dbalek@netbeans.org> Log: Issue #199156 - deadlock possible if call JavaInsertBreakAction when holding document lock - fixed.