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.
Summary: | Deadlock on IDE startup: AWT-EQ-0 x Warm Up | ||
---|---|---|---|
Product: | platform | Reporter: | Tomas Danek <musilt2> |
Component: | JDK Problems | Assignee: | Antonin Nebuzelsky <anebuzelsky> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | cyhelsky, jlahoda, MackSix, mmirilovic, stezeb, tboudreau |
Priority: | P1 | Keywords: | JDK_SPECIFIC |
Version: | 7.2 | ||
Hardware: | PC | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
threaddump
threaddump#2 |
Description
Tomas Danek
2012-04-05 09:15:00 UTC
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. 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 *** |