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.
Build 200707200000 IDE hung without drawing, but the OS buttons, such as "minimize" work. WinXP sp2. This is the second time it happened so far today. At the time of the hang there is a target platform being debugged (from recent source). But for at least minutes, the debugger wasn't used, I was editing and such. The first time, I exited the debug target and took a stack trace and then IDE came back as if responding to the Ctrl-BREAK; I'm not entirely certain of events but that's what i remember. The second time, I took a before stack trace, then exited the debugged IDE, then took an after stack trace. The IDE was/is still hung. The two stack traces are attached.
Created attachment 45486 [details] hanging IDE before exiting debug target
Created attachment 45487 [details] hanging IDE after exiting debug target
I'm not sure if it belongs here, could you please investigate the thread dumps?
Is this reproducible? It looks like somebody did not release document lock for a java document.
Reproducible? No. Though it did happen twice one day. Should it happen again, is there any way to get a dump of who owns what locks? Vita is correct, something must be holding the document write lock.
Reproducible? YES! This takes a bit of explaining, if you have jVi running and you have the following file (note the cursor is on the "a"). -|a(b)c -a(b)c Enter: c%X<ESC> that is a 4 character command, this results in -|Xc -a(b)c Move the cursor so that it looks like the following, then enter ".", single character which repeats the last command -Xc -|a(b)c The IDE is now hung. Here's what these commands do. The 'c' is the change commmand. The '%' executes the "GotoMatchBrace" command, and this is a vi motion. So the 'c%' does "change to where the gotoMatch motion takes you, inclusive. After entering 'c%' you see -|c and vi is in input mode, then the "X<ESC>" inserts 'X' and teh <ESC> exits input mode. So now when the '.' command is executed, it repeats the last modify command, in this case "c%X<ESC>", *and* to do this it takes the atomicLock; and this probably prevents the FindBraceMatch thread from proceeding and so the eventQ hangs waiting for it to finish. BTW, the reason it takes the atomicLock is so that a single "undo" will handle anything that the '.' command does, in this case both the delete of "a(b)" and the insert of "X". If issue 103467 were fixed, then it would not be needed to use the atomicLock. I'll go post a question in that issue...
Cool, thanks for the analysis Ernie. I think I could fix it in braces matching even though having #103467 fixed is obviously preferable. The MasterMatcher could check if the document it is working on is locked and if so, perform the match-and-go operation synchronously. IMO although unlikely what you do in jVi [*] can generally be done by anybody else and the braces matching should not deadlock. [*] - That is, lock the document and under the lock invoke the go-to-matching-brace action.
If this is fixed as you suggest, goto brace match doesn't deadlock, then no pressure to find alternate solutions. That would be great.
The action now runs synchronously for locked documents. Ernie, could you please check the fix with jVi? Thanks. Checking in MasterMatcher.java; /cvs/editor/bracesmatching/src/org/netbeans/modules/editor/bracesmatching/MasterMatcher.java,v <-- MasterMatcher.java new revision: 1.5; previous revision: 1.4 done
The change avoids the deadlock. (I'm marking this issue as verified, not sure about usual procedure)
Yes, thanks for verifying it.