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 110500 - IDE hangs and doesn't redraw
Summary: IDE hangs and doesn't redraw
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Vitezslav Stejskal
Keywords: THREAD
Depends on: 103467
  Show dependency tree
Reported: 2007-07-21 20:19 UTC by err
Modified: 2007-11-05 13:44 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

hanging IDE before exiting debug target (25.51 KB, text/plain)
2007-07-21 20:20 UTC, err
hanging IDE after exiting debug target (18.33 KB, text/plain)
2007-07-21 20:21 UTC, err

Note You need to log in before you can comment on or make changes to this bug.
Description err 2007-07-21 20:19:10 UTC
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.
Comment 1 err 2007-07-21 20:20:56 UTC
Created attachment 45486 [details]
hanging IDE before exiting debug target
Comment 2 err 2007-07-21 20:21:31 UTC
Created attachment 45487 [details]
hanging IDE after exiting debug target
Comment 3 Max Sauer 2007-07-25 10:44:11 UTC
I'm not sure if it belongs here, could you please investigate the thread dumps?
Comment 4 Vitezslav Stejskal 2007-07-25 10:57:34 UTC
Is this reproducible? It looks like somebody did not release document lock for a java document.
Comment 5 err 2007-07-25 16:27:28 UTC
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.
Comment 6 err 2007-07-26 00:37:03 UTC
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").
Enter: c%X<ESC>
that is a 4 character command, this results in
Move the cursor so that it looks like the following, then enter ".", single character which repeats the last command
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
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...
Comment 7 Vitezslav Stejskal 2007-07-26 13:52:28 UTC
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. 
Comment 8 err 2007-07-26 14:42:47 UTC
If this is fixed as you suggest, goto brace match doesn't deadlock, then no pressure to find alternate solutions. That
would be great.
Comment 9 Vitezslav Stejskal 2007-08-21 17:22:56 UTC
The action now runs synchronously for locked documents. Ernie, could you please check the fix with jVi? Thanks.

Checking in;
/cvs/editor/bracesmatching/src/org/netbeans/modules/editor/bracesmatching/,v  <--
new revision: 1.5; previous revision: 1.4
Comment 10 err 2007-08-21 22:57:17 UTC
The change avoids the deadlock.

(I'm marking this issue as verified, not sure about usual procedure)
Comment 11 Vitezslav Stejskal 2007-08-22 11:39:28 UTC
Yes, thanks for verifying it.