Bug 132997 - NetBeans freezes while editing
NetBeans freezes while editing
Status: RESOLVED DUPLICATE of bug 135004
Product: java
Classification: Unclassified
Component: Editor
6.x
All All
: P2 with 1 vote (vote)
: 6.x
Assigned To: Jan Lahoda
issues@java
: RANDOM, THREAD
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-16 14:03 UTC by vieiro
Modified: 2008-06-23 14:52 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Thread dump (15.60 KB, text/plain)
2008-04-16 14:05 UTC, vieiro
Details
Thread dump (seek for 0xa364c6c0) (15.60 KB, text/plain)
2008-04-16 14:05 UTC, vieiro
Details
Initial part of messages.log (37.52 KB, text/plain)
2008-04-16 16:14 UTC, vieiro
Details
New Stack Trace (15.67 KB, text/plain)
2008-04-28 20:11 UTC, vieiro
Details
My Thread Dump (28.35 KB, text/plain)
2008-04-28 21:36 UTC, dyegoleal
Details
Stack Again (40.36 KB, text/plain)
2008-04-30 19:51 UTC, dyegoleal
Details
New stack trace (40.99 KB, text/plain)
2008-05-26 12:59 UTC, vieiro
Details
New stack trace (NO JVI SUPPORT) (28.15 KB, text/plain)
2008-05-26 16:13 UTC, vieiro
Details
Thread Dump using today build - 200805291203 - HELP ! (26.29 KB, text/plain)
2008-06-02 14:06 UTC, dyegoleal
Details

Note You need to log in before you can comment on or make changes to this bug.
Description vieiro 2008-04-16 14:03:54 UTC
NetBeans hangs while editing. I can't reproduce it, but I took a thread dump when NetBeans was hung. Attached.
Comment 1 vieiro 2008-04-16 14:05:17 UTC
Created attachment 60274 [details]
Thread dump
Comment 2 vieiro 2008-04-16 14:05:47 UTC
Created attachment 60275 [details]
Thread dump (seek for 0xa364c6c0)
Comment 3 Jan Becicka 2008-04-16 14:26:36 UTC
Bad thread is "exec_null_28" IMO. It waits for java.awt.Component$AWTTreeLock but outside of AWT event queue, which is
ilegal.

Comment 4 Jan Becicka 2008-04-16 14:27:59 UTC
You executed some ant scripts, right? How did you execute them? Thanks
Comment 5 Jan Lahoda 2008-04-16 14:32:03 UTC
Could you please attach your messages.log? Thanks.
Comment 6 Jan Becicka 2008-04-16 15:11:33 UTC
Not reproducible -> P2.
Comment 7 vieiro 2008-04-16 16:10:46 UTC
I executed the ant scripts via "Run" and/or "Clean & Build" and/or "Build". I seldom use others.

I'm attaching (part) of messages.log
Comment 8 vieiro 2008-04-16 16:14:24 UTC
Created attachment 60287 [details]
Initial part of messages.log
Comment 9 Jan Lahoda 2008-04-16 16:41:19 UTC
I think that cause is most likely that someone locked the document (atomic lock or write lock) and forgot to unlock it.
While trying to find the culprit, I have found a few suspicious places (issue #133022 and issue #133018, one more is in
languages.php, but this is deprecated and will be removed). I do not think any of these is the culprit.

Reporter, from the log it seems you are using jvi in NetBeans, is it true? I took a look at jvi sources, but I have no
conclusive results. In Normal.n_opencmd, it seems that endInsertUndo might not be called although the beginInsertUndo
was called (and beginInsertUndo acquires atomicLock, if I read the code correctly), but it might be unlocked sometime
later. Ernie, any insights?

I filled issue #133025 for the Swing access outside AWT Thread.
Comment 10 vieiro 2008-04-16 17:02:18 UTC
Using jvi you ask? Well, of course! jvi is key to my productivity ;-) I'm enjoying myself with jvi 1.1.4 on top of NB
6.1RC1, too good to be true!

I was editing a Java file when this happened (opening a completion popup, I think). All other files in the editor were
Java files (I think, not sure though), so I don't think this is related to a tag based editor.

If it ever happens again I'll try to take a screenshot (repaint was working right) so as to further track this.

Cheers,
Antonio
Comment 11 err 2008-04-17 03:34:50 UTC
jVi's beginInsertUndo does not take the document lock. It does its best to arrange to collect undoable edits into an
undo group. The undo group is "closed" at endInsertUndo.

The beginUndo/endUndo is the one that takes the document lock. This is done when all the changes jVi is making are
programatic, no user intervention involved (except for the confirm operation on the substitue command, eg :%s/foo/bar/c)
which prompts modally before making any changes.

One tricky example of a programatic change is the '.' command which repeats the last command. And the last command may
have been an insert command. In that case, "inRedo" is true and beginInsertUndo does nothing. But I digress.

It's been a while since there's been a locking issue, but they have shown up when jVi has the lock and it invokes some
feature in NB that takes the lock. But there will usually be something on the stack that at least hints at some jVi
involvement, or at least some editor involvement. Jvi should never return from the event thread, or any other thread for
that matter, when holding an atomic lock.  These stacks are pretty thread-bare.

Good luck, and let me know if I can be of assistance.
Comment 12 dyegoleal 2008-04-17 12:32:43 UTC
I suffer whith this too :( !
Comment 13 Jan Lahoda 2008-04-18 10:36:35 UTC
dyegoleal, do you also use jVi?
Comment 14 dyegoleal 2008-04-18 12:13:47 UTC
No , Pure 6.1 RC1...

The hangs is normal in editor :(

I want to use 6.1 in my company but.... hangs hangs hangs :(

HELP! ! hehehehhe
Comment 15 Jan Lahoda 2008-04-18 13:18:19 UTC
Could you please generate a few thread dumps and attach them here? Thanks.
http://wiki.netbeans.org/GenerateThreadDump
Comment 16 vieiro 2008-04-28 20:11:09 UTC
Created attachment 60770 [details]
New Stack Trace
Comment 17 vieiro 2008-04-28 20:17:10 UTC
It happened again today, with the newest NB 6.1. 

Same behaviour as before: IDE freezes, although AWT repaint thread keeps on running.
Comment 18 dyegoleal 2008-04-28 21:36:29 UTC
Created attachment 60771 [details]
My Thread Dump
Comment 19 dyegoleal 2008-04-28 21:37:02 UTC
Again !!! 
Comment 20 Jan Lahoda 2008-04-29 12:35:41 UTC
dyegoleal, your problem is different - see issue #132662 (I have added you on CC of that bug. If I understand everything
correctly, it is scheduled for Patch 1 of NetBeans 6.1).

vieiro, the second thread dump is different from the first one. In fact, I do not see any deadlock in the second thread
dump - the AWT is performing a task (possibly taking a long time or infinite). Not quite sure that exactly is going
there, as most of the processing is jVi (the NetBeans parts seem quite straightforward to me).
Comment 21 dyegoleal 2008-04-30 19:51:35 UTC
Created attachment 60895 [details]
Stack Again
Comment 22 dyegoleal 2008-04-30 19:52:05 UTC
Again !!! Please see the stack !!!
Comment 23 Jan Lahoda 2008-04-30 22:50:52 UTC
dyegoleal, the last thread dump is issue #132662 again.
Comment 24 vieiro 2008-05-26 12:59:00 UTC
Created attachment 61910 [details]
New stack trace
Comment 25 vieiro 2008-05-26 16:11:12 UTC
I'm going to attach just another stack trace, let me know if these are too many stack traces.

Cheers,
Antonio
Comment 26 vieiro 2008-05-26 16:13:16 UTC
Created attachment 61932 [details]
New stack trace (NO JVI SUPPORT)
Comment 27 dyegoleal 2008-06-02 14:06:06 UTC
Created attachment 62250 [details]
Thread Dump using today build  - 200805291203 - HELP !
Comment 28 Jan Lahoda 2008-06-02 14:32:23 UTC
dyegoleal: issue #132662 again, IMO. I have added a note there.
vieiro: the deadlock in your last thread dump is covered by issue #133073.
Comment 29 dyegoleal 2008-06-02 14:44:08 UTC
I'm in windows !!! XP SP3 (but in Sp2 this bugs is fired too !)
Comment 30 Jan Lahoda 2008-06-23 14:52:21 UTC
The original deadlock is very similar to deadlock described in issue #135004.

*** This issue has been marked as a duplicate of 135004 ***


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