I also managed to reproduce the deadlock using JDK 1.7.0_04. This time the dump has been obtained by sending QUIT signal to the JVM process and it says that only two threads are involved:

[INFO] Found one Java-level deadlock:
[INFO] =============================
[INFO] "NbStatusDisplayer":
[INFO]   waiting for ownable synchronizer 0x00000000e0624808, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
[INFO]   which is held by "AWT-EventQueue-0"
[INFO] "AWT-EventQueue-0":
[INFO]   waiting to lock monitor 0x00007fe3dc089d50 (object 0x00000000e0624960, a sun.awt.PostEventQueue),
[INFO]   which is held by "NbStatusDisplayer"
[INFO] 
[INFO] Java stack information for the threads listed above:
[INFO] ===================================================

[INFO] "NbStatusDisplayer":
[INFO]  at sun.misc.Unsafe.park(Native Method)
[INFO]  - parking to wait for  <0x00000000e0624808> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
[INFO]  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
[INFO]  at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
[INFO]  at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
[INFO]  at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
[INFO]  at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
[INFO]  at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
[INFO]  at java.awt.EventQueue.postEventPrivate(EventQueue.java:235)
[INFO]  at java.awt.EventQueue.postEvent(EventQueue.java:221)
[INFO]  at sun.awt.PostEventQueue.flush(SunToolkit.java:2116)
[INFO]  - locked <0x00000000e0624960> (a sun.awt.PostEventQueue)
[INFO]  at sun.awt.SunToolkit.flushPendingEvents(SunToolkit.java:563)
[INFO]  at java.awt.EventQueue.postEvent(EventQueue.java:220)
[INFO]  at java.awt.EventQueue.invokeLater(EventQueue.java:1188)
[INFO]  at javax.swing.SwingUtilities.invokeLater(SwingUtilities.java:1287)
[INFO]  at org.netbeans.core.windows.view.ui.StatusLine.stateChanged(StatusLine.java:95)
[INFO]  at org.openide.util.ChangeSupport.fireChange(ChangeSupport.java:133)
[INFO]  at org.openide.util.ChangeSupport.fireChange(ChangeSupport.java:119)
[INFO]  at org.netbeans.core.NbStatusDisplayer.remove(NbStatusDisplayer.java:171)
[INFO]  at org.netbeans.core.NbStatusDisplayer.access$300(NbStatusDisplayer.java:62)
[INFO]  at org.netbeans.core.NbStatusDisplayer$MessageImpl.run(NbStatusDisplayer.java:197)
[INFO]  at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1411)
[INFO]  at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1991)

[INFO] "AWT-EventQueue-0":
[INFO]  at sun.awt.PostEventQueue.noEvents(SunToolkit.java:2104)
[INFO]  - waiting to lock <0x00000000e0624960> (a sun.awt.PostEventQueue)
[INFO]  at sun.awt.SunToolkit.isPostEventQueueEmpty(SunToolkit.java:577)
[INFO]  at java.awt.EventQueue.detachDispatchThread(EventQueue.java:1048)
[INFO]  at java.awt.EventDispatchThread.run(EventDispatchThread.java:103)
[INFO] 
[INFO] Found 1 deadlock.

I haven't been able to reproduce this on JDK 1.6.0_32 (yet)...

I think that the root of the problem is in JDK 1.7, namely in the method:

java.awt.EventQueue.detachDispatchThread

...where it calls SunToolkit.isPostEventQueueEmpty() while holding global "pushPopLock".

The static method SunToolkit.isPostEventQueueEmpty() invokes a synchronized method on a singleton PostEventQueue object. Also other methods on this singleton PostEventQueue are synchronized and some of them (for example PostEventQueue.flush() invoked from static SunToolkit.flushPendingEvents()) are also synchronized and call into the java.awt.EventQueue which tries to get the global "pushPopLock" - hece the deadlock.

SunToolkit.isPostEventQueueEmpty() (or any of it's methods that delegate to PostEventQueue singleton) should not be called while holding global "pushPopLock" in java.awt.EventQueue...

That's clearly a JDK bug (SunToolkit/AWT). While looking at the SunToolkit code I spoted another one: The following code:


    private static final Lock flushLock = new ReentrantLock();
    private static boolean isFlushingPendingEvents = false;

    /*
     * Flush any pending events which haven't been posted to the AWT
     * EventQueue yet.
     */
    public static void flushPendingEvents()  {
        flushLock.lock();
        try {
            // Don't call flushPendingEvents() recursively
            if (!isFlushingPendingEvents) {
                isFlushingPendingEvents = true;
                AppContext appContext = AppContext.getAppContext();
                PostEventQueue postEventQueue =
                    (PostEventQueue)appContext.get(POST_EVENT_QUEUE_KEY);
                if (postEventQueue != null) {
                    postEventQueue.flush();
                }
            }
        } finally {
            isFlushingPendingEvents = false;
            flushLock.unlock();
        }
    }


... is clearly wrong. The isFlushingPendingEvents flag is reset in finally block regardless of whether it was true or false at the entry to the try block. The 1st nested call to flushPendingEvents() prevents recursion but it also resets the flag so that the second nested call is allowed...

My proposal to fix this bug is to rewrite the SunToolkit.PostEventQueue to use the same global "pushPopLock" Lock instance that java.awt.EnetQueue uses for it's synchronization instead of "synchronized" instance methods...

I submited 2 bug reports for JDK. Te 1st (deadlock involving a mutex Lock from java.awt.EventQueue and SunToolkit.PostEven) is Bug ID: 7181081, the 2nd (wrong logic to prevent recursion in SunToolkit.flushPendingEvents()) is Bug ID: 7181082.
Let's hope for quick response from JDK team...

Thanks for reporting to JDK. Closing this issue on our side as wontfix.

*** Bug 223544 has been marked as a duplicate of this bug. ***