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.
Product Version = NetBeans IDE Dev (Build 201204040400) (#8a44e6982ae3) Operating System = Mac OS X version 10.7.3 running on amd64 Java; VM; Vendor = 1.7.0_04-ea; Java HotSpot(TM) 64-Bit Server VM 23.0-b19; Oracle Corporation Runtime = Java(TM) SE Runtime Environment 1.7.0_04-ea-b18 Java Home = /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre System Locale; Encoding = en_US (nb); UTF-8 ----------------------------------- During IDE startup (full thread dump attached). From my point of view there's nothing wrong on NB side, should be investigated by JDK team. Found one Java-level deadlock: ============================= "AWT-EventQueue-0": waiting to lock monitor 0x00007ff87115dd30 (object 0x00000007d00b9088, a sun.awt.PostEventQueue), which is held by "Warm Up" "Warm Up": waiting for ownable synchronizer 0x00000007d06338b0, (a java.util.concurrent.locks.ReentrantLock$NonfairSync), which is held by "AWT-EventQueue-0" Java stack information for the threads listed above: =================================================== "AWT-EventQueue-0": at sun.awt.PostEventQueue.noEvents(SunToolkit.java:2082) - waiting to lock <0x00000007d00b9088> (a sun.awt.PostEventQueue) at sun.awt.SunToolkit.isPostEventQueueEmpty(SunToolkit.java:575) at java.awt.EventQueue.detachDispatchThread(EventQueue.java:1048) at java.awt.EventDispatchThread.run(EventDispatchThread.java:103) "Warm Up": at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000007d06338b0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290) at java.awt.EventQueue.postEventPrivate(EventQueue.java:235) at java.awt.EventQueue.postEvent(EventQueue.java:221) at sun.awt.PostEventQueue.flush(SunToolkit.java:2094) - locked <0x00000007d00b9088> (a sun.awt.PostEventQueue) at sun.awt.SunToolkit.flushPendingEvents(SunToolkit.java:561) at java.awt.EventQueue.postEvent(EventQueue.java:220) at java.awt.EventQueue.invokeLater(EventQueue.java:1188) at javax.swing.SwingUtilities.invokeLater(SwingUtilities.java:1287) at org.netbeans.core.windows.services.DialogDisplayerImpl.notify(DialogDisplayerImpl.java:281) - locked <0x00000007ff2fc488> (a org.netbeans.core.windows.services.DialogDisplayerImpl$1AWTQuery) at org.netbeans.core.windows.services.DialogDisplayerImpl.notify(DialogDisplayerImpl.java:167) at org.netbeans.modules.autoupdate.pluginimporter.libinstaller.JUnitLibraryInstaller.install(JUnitLibraryInstaller.java:161) at org.netbeans.modules.autoupdate.pluginimporter.libinstaller.InstallLibraryTask.run(InstallLibraryTask.java:93) at org.netbeans.core.startup.WarmUpSupport.run(WarmUpSupport.java:94) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1452) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2032) Found 1 deadlock. Heap PSYoungGen total 258816K, used 250224K [0x00000007f0000000, 0x0000000800000000, 0x0000000800000000) eden space 258176K, 96% used [0x00000007f0000000,0x00000007ff3bc300,0x00000007ffc20000) from space 640K, 100% used [0x00000007fff60000,0x0000000800000000,0x0000000800000000) to space 1984K, 0% used [0x00000007ffc20000,0x00000007ffc20000,0x00000007ffe10000) ParOldGen total 59200K, used 41365K [0x00000007d0000000, 0x00000007d39d0000, 0x00000007f0000000) object space 59200K, 69% used [0x00000007d0000000,0x00000007d2865740,0x00000007d39d0000) PSPermGen total 75008K, used 43133K [0x00000007b8000000, 0x00000007bc940000, 0x00000007d0000000) object space 75008K, 57% used [0x00000007b8000000,0x00000007baa1f4c8,0x00000007bc940000)
Created attachment 117871 [details] threaddump
Tonda, could you please report this to JDK team ASAP ? ... we need somebody from JDk team to look at it and evaluate the reason of regression. Tomas will investigate how often this case should happen and let us know today. Thanks in advance.
I am not able to reproduce (~10 attempts), but I think I've seen it at least twice this week (i.e. on JDK7u4 b18). But cannot confim, since I was not able to generate threaddump during the other freeze.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159231
The actual open bug is at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159230
*** Bug 211811 has been marked as a duplicate of this bug. ***
*** Bug 211378 has been marked as a duplicate of this bug. ***
*** Bug 210938 has been marked as a duplicate of this bug. ***
*** Bug 214266 has been marked as a duplicate of this bug. ***
Imho the priority of the jdk bug should be raised from P3 to P2 as it is now confirmed that it happens on other platforms. Reopening this issue to keep track of the problem.
Increased priority of the Java bug.
*** Bug 214634 has been marked as a duplicate of this bug. ***
*** Bug 215163 has been marked as a duplicate of this bug. ***
The currently last comment in CR 7159230 claims that this should not happen for "correct" application where sun.awt.SunToolkit is initialized on correct place/in correct way. Did someone check how is that class initialized during NB startup (compared to a trivial GUI app), and see if we can reasonably workaround?
IMO calling EventQueue.invokeLater() should never, ever, ever be a blocking call - the whole point of it is to schedule work that you cannot safely do, to avoid deadlocks and similar problems. So having that method take any lock is a very, very bad idea. At the absolute *most*, EventQueue might use a synchronized list (and even that is an optimization). At the very least it could detect that another thread is waiting on the lock and do some custom behavior in that case (maybe just skip the [unnecessary?] call to flushPendingEvents). Seems like somebody was trying to be too clever. On the other hand, there are plenty of workarounds available: - A warm up task like this can run perfectly safely in the event queue - why not hang it off of a WindowListener on the main window instead? - Probably just about any change that alters the threading or timing of the problem call would probably make this particular deadlock (but not the problem) disappear - it's probably worth some sort of hotfix - Push our own EventQueue with different behavior in postEvent() (if the rest of EventQueue is correct, the call to flushPendingEvents() could be left out and the rest *should* work - it doesn't make much sense there)
it seems the actual bug where this is addressed is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 (7159231 -> 7159230 -> 7177040)
Created attachment 122487 [details] threaddump#2 I think I just ran into the same problem - so grabbed a threaddump for someone more knowledgeable than me to check over. System is Win 7 x64 java version "1.7.0_05" Java(TM) SE Runtime Environment (build 1.7.0_05-b05) Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode) db
After upgrading to 7u6 final this is happening to me every day: Found one Java-level deadlock: ============================= "RepositoryUpdater.worker": waiting for ownable synchronizer 0x00000001243f6958, (a java.util.concurrent.locks.ReentrantLock$NonfairSync), which is held by "AWT-EventQueue-1" "AWT-EventQueue-1": waiting to lock monitor 0x00007fef65baacf8 (object 0x0000000124400b18, a sun.awt.PostEventQueue), which is held by "Warm Up" "Warm Up": waiting for ownable synchronizer 0x00000001243f6958, (a java.util.concurrent.locks.ReentrantLock$NonfairSync), which is held by "AWT-EventQueue-1" Java stack information for the threads listed above: =================================================== "RepositoryUpdater.worker": at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000001243f6958> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290) at java.awt.EventQueue.isDispatchThreadImpl(EventQueue.java:999) at java.awt.EventQueue.isDispatchThread(EventQueue.java:994) at javax.swing.SwingUtilities.isEventDispatchThread(SwingUtilities.java:1362) at org.netbeans.modules.progress.spi.Controller.runImmediately(Controller.java:214) at org.netbeans.modules.progress.spi.Controller.displayNameChange(Controller.java:200) at org.netbeans.modules.progress.spi.InternalHandle.requestDisplayNameChange(InternalHandle.java:333) - locked <0x0000000126946030> (a org.netbeans.modules.progress.spi.InternalHandle) at org.netbeans.api.progress.ProgressHandle.setDisplayName(ProgressHandle.java:211) at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:5174) at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.access$4800(RepositoryUpdater.java:4879) at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2$1.run(RepositoryUpdater.java:5124) at org.netbeans.modules.parsing.impl.RunWhenScanFinishedSupport.performScan(RunWhenScanFinishedSupport.java:96) at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:5120) at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:5116) at org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:176) at org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:360) at org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:72) at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.run(RepositoryUpdater.java:5116) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1452) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2032) "AWT-EventQueue-1": at sun.awt.PostEventQueue.noEvents(SunToolkit.java:2104) - waiting to lock <0x0000000124400b18> (a sun.awt.PostEventQueue) at sun.awt.SunToolkit.isPostEventQueueEmpty(SunToolkit.java:577) at java.awt.EventQueue.detachDispatchThread(EventQueue.java:1058) at java.awt.EventDispatchThread.run(EventDispatchThread.java:103) "Warm Up": at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000001243f6958> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290) at java.awt.EventQueue.postEventPrivate(EventQueue.java:237) at java.awt.EventQueue.postEvent(EventQueue.java:223) at sun.awt.PostEventQueue.flush(SunToolkit.java:2116) - locked <0x0000000124400b18> (a sun.awt.PostEventQueue) at sun.awt.SunToolkit.flushPendingEvents(SunToolkit.java:563) at java.awt.EventQueue.postEvent(EventQueue.java:222) at java.awt.EventQueue.invokeLater(EventQueue.java:1198) at javax.swing.SwingUtilities.invokeLater(SwingUtilities.java:1290) at org.netbeans.modules.editor.fold.FoldHierarchyExecution.startComponentChangesListening(FoldHierarchyExecution.java:738) at org.netbeans.modules.editor.fold.FoldHierarchyExecution.init(FoldHierarchyExecution.java:223) at org.netbeans.modules.editor.fold.FoldHierarchyExecution.getOrCreateFoldHierarchy(FoldHierarchyExecution.java:168) - locked <0x00000001265896c0> (a java.lang.Class for org.netbeans.modules.editor.fold.FoldHierarchyExecution) at org.netbeans.api.editor.fold.FoldHierarchy.get(FoldHierarchy.java:148) - locked <0x0000000126589bd8> (a java.lang.Class for org.netbeans.api.editor.fold.FoldHierarchy) at org.netbeans.modules.editor.NbEditorKit.call(NbEditorKit.java:983) at org.netbeans.modules.java.editor.JavaEditorWarmUpTask.run(JavaEditorWarmUpTask.java:170) at org.netbeans.modules.java.editor.JavaEditorWarmUpTask$Provider.run(JavaEditorWarmUpTask.java:93) at org.netbeans.core.startup.WarmUpSupport.run(WarmUpSupport.java:94) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1452) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2032) Found 1 deadlock.
This really needs to be fixed in the EventQueue - there is no reason EventQueue.invokeLater() *needs* to acquire a lock, and anybody who can't figure out how to do it without one probably doesn't understand concurrent programming well enough to be qualified to make changes to it...
(In reply to comment #16) > it seems the actual bug where this is addressed is: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 > > (7159231 -> 7159230 -> 7177040) Correct. Marking this one as duplicate of issue 213926 for clarity. *** This bug has been marked as a duplicate of bug 213926 ***