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.
NB 7.4 RC2 on OS X 10.8.5 frequent hangs (i.e. beachball cursor requiring force-quit) on general activities using java editor. No error message. Hang happens several times when use the Tools -> Analyze Javadoc -> fix all issues. But has also hung following other general editor activities - hard to pinpoint exact issue causing the hang other than the aforementioned javadoc analyze. I have not experienced same issue with NB 7.3 GA version.
Can you please attach thread dump?
Can you provide steps how I capture the thread dump? I can reproduce the error by using the Tools -> Analyze Javadoc and then "apply fixes" and refresh - this will cause the hang up. however, there are not messages return - the NB IDE freezes and can only be reset by a forced shutdown. thank you
additional note on this issue: I can perform the exact same (analyze javadoc) action, using the same project source code, on the same system, using NetBeans IDE 7.3.1 (Build 201306052037) and the IDE does not lock up - i.e. works normally. thank you.
Created attachment 140842 [details] thread dump Info obtained by mail: Java version "1.7.0_40" Java(TM) SE Runtime Environment (build 1.7.0_40-b43) Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
Jirko, are you sure that the tread dump is taken from the frozen IDE. All the threads are actually in "no work" state. Important threads: Editor parser: "Editor Parsing Loop (201309252201)" daemon prio=5 tid=0x00007fe662393000 nid=0x12503 waiting on condition [0x000000016ed42000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x000000012b25ee80> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043) at java.util.concurrent.PriorityBlockingQueue.take(PriorityBlockingQueue.java:539) meaning that everything is done and the parser waits for next request to do. Drawing thread: "AWT-EventQueue-0" prio=5 tid=0x00007fe66217c000 nid=0xc213 waiting on condition [0x00000001657e4000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000001268a50d8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043) at java.awt.EventQueue.getNextEvent(EventQueue.java:543) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161) also everything is painted and waiting for next request.
Created attachment 140942 [details] NB 7.4 RC2 on Mac OSX thread dump following system hang
Created attachment 143415 [details] Thread dump 10 minutes after UI hang I have this problem too, as well as my whole team, and we cannot figure out a workaround. It is becoming a critical issue for us. Here is what we know so far: - This problem only seems to affect our free form projects - Thread dumps look totally healthy. - Background processes continue to happen and the UI updates even though none of the UI is responsive to clicks or key presses. We can reproduce it every time in when we try to save after modifying files in the subversion commit window, and when we interact (move up or down or add new) with the jars in the Java Sources Classpath of the Project Properties window. Other things that seem to crash sometimes are fix imports and anything that shows a progress window or a progress bar in the status bar (at the bottom of the window). We are all on 10.9 OSX with Java 1.7.0_45 and NetBeans 7.4 Patch 2. Let me know if there is anything we can do to help you find this. It is really hurting our productivity.
I have changed the priority to P1 because this crash is a fully reproducible and unavoidable hang.
According to thread dumps, this is JDK bug #8025588 introduced in JDK 7u40. Until this is fixed in JDK, reverting back to JDK 7u25 should solve this issue. *** This bug has been marked as a duplicate of bug 236101 ***