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.
I defined a macro ALT-C which does the following / * * ENTER ...this is the same as auto-commenting a method, field or class. About one in every 20 times, I can get netbeans to completely freeze up by typing ALT-C. It seems to happen more after I make a change to the file structure (such that the editor has to reconfigure itself to add the folding markers etc), then type the key sequence immediately after.
please, provide a thread dump - http://wiki.netbeans.org/GenerateThreadDump when the IDE freeze
Created attachment 59036 [details] Thread dump
The thread dump attached is not complete. It was too much info for the DOS history window. I hope it helps though. In the mean time I'm continuing to run in debug mode (nb.exe) so I'll be ready if it happens again. Thanks.
> It was too much info for the DOS history window You can increase the size of the screen buffer in the console window's properties. Anyway, the problem is most likely caused by the fact the RunMacro action locks the document before preforming the actions recorded in the macro. If these actions try to acquire java source infrastructure lock the IDE is likely to deadlock. This locking should always happen in the opposite order. Would anybody have any idea how situations like this could be prevented in general?
In general there is no nice solution. The simplest solution is to keep the lock ordering which may become non easy task, you have to know which lock you need to acquire (java, projects, ,gsf, editor,...). Introducing some kind of LockManager which cares about locking and ordering for tasks may be helpful.
There should be a clean solution, lets focus for NEXT.
this is most probably the same deadlock as reported in #213026; although the attached stacktrace is not complete. *** This bug has been marked as a duplicate of bug 213026 ***