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.
Build: NetBeans IDE 6.8 (Build 200912041610) VM: Java HotSpot(TM) Client VM, 10.0-b23, Java(TM) SE Runtime Environment, 1.6.0_07-b06 OS: Windows Vista Maximum slowness yet reported was 473674 ms, average is 291560
Created attachment 96681 [details] nps snapshot
It's hard to say what goes on. The AWT thread is blocked by the body of the IndentImpl.indentLock() method, likely by the wait() method on line 139. It looks like some other (non-AWT) thread called the indentLock() and then the AWT call from BaseKit$InsertBreakAction to the method happened. The snapshot indicates there is the scanning in progress so it's possible that the other thread after acquiring the lock waits for some parsing.api stuff and is blocked for long time. Who and why in non-AWT thread called the indentLock() method is a mystery to me. The snapshot may also indicate some of the callstacks incorrectly so maybe the problem is in different place. I suspected IndentImpl.indentLock():147 which calls taskHandler.lock() which then locks all the involved indenters, but at first the call should be visible in the snapshot and for the second at least in current 6.9 trunk build none of the indenters does any locking (none of them have an extraLock).
Since there just two older reports of this kind I am closing the issue as already fixed. We'll see if it appears again.