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.
| Summary: | NetBeans freezes while editing | ||
|---|---|---|---|
| Product: | java | Reporter: | vieiro <vieiro> |
| Component: | Editor | Assignee: | Jan Lahoda <jlahoda> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | blocker | CC: | err, mmirilovic |
| Priority: | P2 | Keywords: | RANDOM, THREAD |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
Thread dump
Thread dump (seek for 0xa364c6c0) Initial part of messages.log New Stack Trace My Thread Dump Stack Again New stack trace New stack trace (NO JVI SUPPORT) Thread Dump using today build - 200805291203 - HELP ! |
||
|
Description
vieiro
2008-04-16 14:03:54 UTC
Created attachment 60274 [details]
Thread dump
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 ilegal. 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. Cheers, Antonio 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. http://wiki.netbeans.org/GenerateThreadDump 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
Again !!! 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]
Stack Again
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. Cheers, Antonio 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 *** |