System: Windows XP, 3 GB RAM, 150 GB HD (80 GB free).
Netbeans 6.1, Build 200807020101
Can't stop debugger, can't shutdown. Tried numerous times. Takes forever to respond.
Created attachment 64268 [details]
Screen cap of IDE
Created attachment 64269 [details]
Screen cap of Windows Task Manager
Created attachment 64270 [details]
Created attachment 64396 [details]
Frozen again. 2nd thread dump attached.
Reassigning to "java".
Seems more like debugger issue to me. Please reassign back in case I'm mistaken, thanks.
I have made a fix preventing Finish Debugger action to be still enabled and non-functional:
changeset d9e81876bce9 in main
The second thread dump does not seem to be related to the debugger. AWT thread is blocked at
which is called by
Reassigning back for further evaluation.
Integrated into 'main-golden', available in build *200807310201* on http://bits.netbeans.org/dev/nightly/
User: Daniel Prusa <email@example.com>
Log: #139636: clear finishing flag on finish() method exit
Created attachment 67923 [details]
NetBeans froze again! Attaching thread dump.
Last dump is from gsf, isn't it?
Moving from ruby/GSF to editor/CSL. Step one: assign to myself ;-)
Step 2: trying to make the owner not myself but the owner of the subcomponent.
Is this still relevant?
Not sure. From the threaddump it looks like a clash between AWT and "GSF Source Worker Thread".
AWT: BaseKit.DefaultKeyTypedAction calls insertString under a document writelock;
JSPKit$JspDefaultKeyTypedAction.insertString calls reformat which tries to acquire the GSF parsing infrastructure's lock.
GSF: A task is running which tries to readlock a document.
Any chance this has been resolved? I am little confused from the latest comments.
Issue has INCOMPLETE status - are we really waiting for additional info from the reporter?
Thanks for any update
It would be nice if the reporter will tell us if it still happen for him in latest trunk builds... Thanks.
Marek, these are yours now ...
Last deadlock is probably due to incorrect order of locking of document and internal old gsf parser lock. mfukala do you
remember if you already fixed this in past or not?
Document locking in AWT thread is done at org.netbeans.editor.BaseKit$DefaultKeyTypedAction.actionPerformed.
This is IMHO already fixed by my changes in JspKit$JspDefaultKeyTypedAction - the indent lock is acquired before locking
closing as fixed