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.

Bug 210752 - Deadlock on IDE startup: AWT-EQ-0 x Warm Up
Summary: Deadlock on IDE startup: AWT-EQ-0 x Warm Up
Status: RESOLVED DUPLICATE of bug 213926
Alias: None
Product: platform
Classification: Unclassified
Component: JDK Problems (show other bugs)
Version: 7.2
Hardware: PC All
: P1 normal (vote)
Assignee: Antonin Nebuzelsky
URL:
Keywords: JDK_SPECIFIC
: 210938 211378 211811 214266 214634 215163 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-04-05 09:15 UTC by Tomas Danek
Modified: 2012-08-22 13:06 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
threaddump (20.46 KB, text/plain)
2012-04-05 09:16 UTC, Tomas Danek
Details
threaddump#2 (39.13 KB, text/plain)
2012-07-28 14:48 UTC, bolsover
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Danek 2012-04-05 09:15:00 UTC
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)
Comment 1 Tomas Danek 2012-04-05 09:16:03 UTC
Created attachment 117871 [details]
threaddump
Comment 2 Marian Mirilovic 2012-04-05 09:37:04 UTC
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.
Comment 3 Tomas Danek 2012-04-05 10:00:24 UTC
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.
Comment 4 Antonin Nebuzelsky 2012-04-05 11:16:38 UTC
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159231
Comment 5 Antonin Nebuzelsky 2012-04-05 12:05:41 UTC
The actual open bug is at

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159230
Comment 6 Antonin Nebuzelsky 2012-05-02 10:45:39 UTC
*** Bug 211811 has been marked as a duplicate of this bug. ***
Comment 7 Marian Mirilovic 2012-06-07 12:32:16 UTC
*** Bug 211378 has been marked as a duplicate of this bug. ***
Comment 8 Marian Mirilovic 2012-06-07 12:39:00 UTC
*** Bug 210938 has been marked as a duplicate of this bug. ***
Comment 9 Petr Cyhelsky 2012-06-15 13:01:20 UTC
*** Bug 214266 has been marked as a duplicate of this bug. ***
Comment 10 Petr Cyhelsky 2012-06-15 13:14:04 UTC
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.
Comment 11 Antonin Nebuzelsky 2012-06-20 10:24:42 UTC
Increased priority of the Java bug.
Comment 12 Ondrej Vrabec 2012-06-22 16:29:12 UTC
*** Bug 214634 has been marked as a duplicate of this bug. ***
Comment 13 Jan Lahoda 2012-07-04 21:32:53 UTC
*** Bug 215163 has been marked as a duplicate of this bug. ***
Comment 14 Jan Lahoda 2012-07-04 21:37:39 UTC
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?
Comment 15 _ tboudreau 2012-07-08 06:05:03 UTC
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)
Comment 16 Petr Cyhelsky 2012-07-13 07:32:45 UTC
it seems the actual bug where this is addressed is:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040

(7159231 -> 7159230 -> 7177040)
Comment 17 bolsover 2012-07-28 14:48:23 UTC
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
Comment 18 David Strupl 2012-08-17 12:09:49 UTC
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.
Comment 19 _ tboudreau 2012-08-17 17:02:01 UTC
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...
Comment 20 Antonin Nebuzelsky 2012-08-22 13:06:09 UTC
(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 ***