NetBeans hangs while editing. I can't reproduce it, but I took a thread dump when NetBeans was hung. Attached.
Created attachment 60274 [details]
Created attachment 60275 [details]
Thread dump (seek for 0xa364c6c0)
Bad thread is "exec_null_28" IMO. It waits for java.awt.Component$AWTTreeLock but outside of AWT event queue, which is
You executed some ant scripts, right? How did you execute them? Thanks
Could you please attach your messages.log? Thanks.
Not reproducible -> P2.
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
Created attachment 60287 [details]
Initial part of messages.log
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.
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.
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.
I suffer whith this too :( !
dyegoleal, do you also use jVi?
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
Could you please generate a few thread dumps and attach them here? Thanks.
Created attachment 60770 [details]
New Stack Trace
It happened again today, with the newest NB 6.1.
Same behaviour as before: IDE freezes, although AWT repaint thread keeps on running.
Created attachment 60771 [details]
My Thread Dump
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).
Created attachment 60895 [details]
Again !!! Please see the stack !!!
dyegoleal, the last thread dump is issue #132662 again.
Created attachment 61910 [details]
New stack trace
I'm going to attach just another stack trace, let me know if these are too many stack traces.
Created attachment 61932 [details]
New stack trace (NO JVI SUPPORT)
Created attachment 62250 [details]
Thread Dump using today build - 200805291203 - HELP !
dyegoleal: issue #132662 again, IMO. I have added a note there.
vieiro: the deadlock in your last thread dump is covered by issue #133073.
I'm in windows !!! XP SP3 (but in Sp2 this bugs is fired too !)
The original deadlock is very similar to deadlock described in issue #135004.
*** This issue has been marked as a duplicate of 135004 ***