JDK-7162144 : Missing AWT thread in headless mode in 7u4 b06
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7u4
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-04-17
  • Updated: 2012-08-06
  • Resolved: 2012-08-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u6 b22Fixed 8Resolved
Related Reports
Relates :  
JDK-7189350 - Fix failed for CR 7162144
Relates :  
JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144
Relates :  
JDK-7081670 - Disposing an AppContext can lead to a spinning EventDispatchThread
Relates :  
JDK-7174704 - [macosx] New issue in 7u6 b12: HeadlessPrintingTest failure
Description
With 7u4 b20 an application running in headless mode is missing AWT thread.

Apparently a regression caused by integration of 7159266 in b20.

The change is breaking many tests of the NetBeans test suite.

See e.g.
http://netbeans.org/bugzilla/show_bug.cgi?id=211305
Comments
SUGGESTED FIX http://cr.openjdk.java.net/~anthony/7u6-16-missingAWTThread-7162144.0/
10-07-2012
EVALUATION The hang can be eliminated by discarding all pending events when the event thread is interrupt()'ed. However, the invokeAndWait() that currently appears to be hung will now throw an InterruptedException: [junit] WARNING [org.openide.awt.Toolbar]: Too long AWTTask: 4,518 ms for org.openide.awt.Toolbar$Folder@51e2696f(FolderList{MultiFileObject@64af4b04[Toolbars/Memory]}) [junit] ------------- ---------------- --------------- [junit] Testcase: org.netbeans.junit.NbModuleSuite$S@6379c2c4: Caused an ERROR [junit] The event is discarded due to Event Thread interruption [junit] java.lang.InterruptedException: The event is discarded due to Event Thread interruption [junit] at java.awt.EventQueue.invokeAndWait(EventQueue.java:1277) [junit] at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1346) [junit] at org.netbeans.junit.NbModuleSuite$S.runInRuntimeContainer(NbModuleSuite.java:949) [junit] at org.netbeans.junit.NbModuleSuite$S.access$100(NbModuleSuite.java:660) [junit] at org.netbeans.junit.NbModuleSuite$S$1.protect(NbModuleSuite.java:679) [junit] at junit.framework.TestResult.runProtected(TestResult.java:128) [junit] at org.netbeans.junit.NbModuleSuite$S.run(NbModuleSuite.java:677) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906) [junit] [junit] [junit] INFO [org.netbeans.core.netigso.Netigso]: bundle ###@###.###.R37x_v20110808-1106 256 [junit] INFO [org.netbeans.core.netigso.Netigso]: bundle ###@###.###.R37x_v20110808-1106 stopped [junit] INFO [org.netbeans.core.netigso.Netigso]: bundle ###@###.###.R37x_v20110808-1106 stopped [junit] WARNING [org.netbeans.CLIHandler]: Cannot unlock null [junit] Test org.netbeans.core.windows.awt.ValidateLayerMenuTest FAILED
03-07-2012
EVALUATION This is a regression of 7081670. Backing out that fix restores the correct behavior.
03-07-2012
EVALUATION Note that JDK 8 is also affected by a missing fix for 7174704 (which is temporarily blocked by a HotSpot bug 7166725). So for now we have to fix this issue in JDK 7u6, and port the fix to 8 later.
03-07-2012
EVALUATION Note that there were two versions of a fix for 7081670 proposed: one "full" and another one - "minimal" [1]. If I back out the full version, and apply the minimal one instead, the ant task won't hang. [1] http://mail.openjdk.java.net/pipermail/awt-dev/2011-August/001882.html
03-07-2012
EVALUATION The issue is reproducible. Interesting, that the AWTShutdown thread is missing as well when this happens. Here's the stack trace: 2012-07-02 19:02:51 Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.2-b05 mixed mode): "Attach Listener" daemon prio=5 tid=0x000000010221e800 nid=0x870b waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "TimerQueue" daemon prio=5 tid=0x000000010b640800 nid=0x8003 waiting on condition [0x0000000128bb0000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000007ff16bd20> (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.DelayQueue.take(DelayQueue.java:209) at javax.swing.TimerQueue.run(TimerQueue.java:171) at java.lang.Thread.run(Thread.java:722) "Java2D Disposer" daemon prio=5 tid=0x000000010c027800 nid=0x7503 in Object.wait() [0x000000010d5fc000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000007ed54b0e0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135) - locked <0x00000007ed54b0e0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151) at sun.java2d.Disposer.run(Disposer.java:145) at java.lang.Thread.run(Thread.java:722) "Timer-0" daemon prio=5 tid=0x000000010c3f9800 nid=0x4e07 in Object.wait() [0x0000000108909000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000007ed19a1d8> (a java.util.TaskQueue) at java.lang.Object.wait(Object.java:503) at java.util.TimerThread.mainLoop(Timer.java:526) - locked <0x00000007ed19a1d8> (a java.util.TaskQueue) at java.util.TimerThread.run(Timer.java:505) "Thread-4" daemon prio=5 tid=0x0000000100a11000 nid=0x6603 in Object.wait() [0x000000010add9000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000007ece6af48> (a java.util.LinkedList) at java.lang.Object.wait(Object.java:503) at java.util.prefs.AbstractPreferences$EventDispatchThread.run(AbstractPreferences.java:1476) - locked <0x00000007ece6af48> (a java.util.LinkedList) "AWT-AppKit" daemon prio=5 tid=0x000000010c02d800 nid=0x707 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Bundle File Closer" daemon prio=5 tid=0x00000001024d5000 nid=0x5103 in Object.wait() [0x0000000109700000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000007ecaae648> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread) at java.lang.Object.wait(Object.java:503) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:400) - locked <0x00000007ecaae648> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:336) "CLI Requests Server" daemon prio=5 tid=0x0000000100a2a800 nid=0x4107 runnable [0x0000000108703000] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398) at java.net.ServerSocket.implAccept(ServerSocket.java:522) at java.net.ServerSocket.accept(ServerSocket.java:490) at org.netbeans.CLIHandler$Server.run(CLIHandler.java:1085) "Active Reference Queue Daemon" daemon prio=5 tid=0x00000001009a0800 nid=0x4007 in Object.wait() [0x0000000108600000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000007ec361010> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135) - locked <0x00000007ec361010> (a java.lang.ref.ReferenceQueue$Lock) at org.openide.util.lookup.implspi.ActiveQueue$Daemon.run(ActiveQueue.java:174) - locked <0x00000007ec361010> (a java.lang.ref.ReferenceQueue$Lock) "Service Thread" daemon prio=5 tid=0x000000010207a800 nid=0x4803 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread1" daemon prio=5 tid=0x0000000102071000 nid=0x4703 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" daemon prio=5 tid=0x0000000102078800 nid=0x4603 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=5 tid=0x0000000102075800 nid=0x4503 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=5 tid=0x0000000102034800 nid=0x3503 in Object.wait() [0x0000000107466000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000007ec11ac70> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135) - locked <0x00000007ec11ac70> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177) "Reference Handler" daemon prio=5 tid=0x0000000102034000 nid=0x3403 in Object.wait() [0x0000000107363000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000007ec4331f8> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:503) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133) - locked <0x00000007ec4331f8> (a java.lang.ref.Reference$Lock) "main" prio=5 tid=0x000000010084b000 nid=0x1c03 in Object.wait() [0x0000000100400000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000007ed68d750> (a java.awt.EventQueue$1AWTInvocationLock) at java.lang.Object.wait(Object.java:503) at java.awt.EventQueue.invokeAndWait(EventQueue.java:1232) - locked <0x00000007ed68d750> (a java.awt.EventQueue$1AWTInvocationLock) at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1346) at org.netbeans.junit.NbModuleSuite$S.runInRuntimeContainer(NbModuleSuite.java:949) at org.netbeans.junit.NbModuleSuite$S.access$100(NbModuleSuite.java:660) at org.netbeans.junit.NbModuleSuite$S$1.protect(NbModuleSuite.java:679) at junit.framework.TestResult.runProtected(TestResult.java:128) at org.netbeans.junit.NbModuleSuite$S.run(NbModuleSuite.java:677) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906) "VM Thread" prio=5 tid=0x0000000102031800 nid=0x3303 runnable "GC task thread#0 (ParallelGC)" prio=5 tid=0x000000010200b000 nid=0x3103 runnable "GC task thread#1 (ParallelGC)" prio=5 tid=0x000000010200b800 nid=0x3203 runnable "VM Periodic Task Thread" prio=5 tid=0x000000010208b000 nid=0x4903 waiting on condition JNI global references: 684
02-07-2012
EVALUATION According to Jiri Skrivanek (###@###.###) we don't have a small test case. Jiri provided a test case (now attached in this bug report) which is not small, but you only need to do the following steps: - download 7162144TestCase.zip (also available at http://beetle.cz.oracle.com/data/transfer/jskrivanek/7162144TestCase.zip) - unzip it somewhere - cd 7162144TestCase - ant With latest 7u6 and 8 builds you can see the execution of ant hang (until a several minutes of timeout are reached). On older JDKs it finishes soon (regardless of the actual ant build result which is not important).
29-06-2012
EVALUATION Marking this bug as incomplete: please provide a short test case to reproduce the issue. I've tried a simple test: import java.awt.*; public class test { public static void main(String[] args) throws Exception { java.awt.EventQueue.invokeAndWait(new Runnable() { public void run() { System.err.println("Hello event!"); } }); } } And it passes in the headless mode on the Mac with both JDK 8 and latest 7u6 builds.
28-06-2012
EVALUATION It seems that 7081670 is most likely the cause. Specifically, the changes to EventDispatchThread.pumpOneEventForFilters(int): in case the event thread catches an InterruptedException, it sets the shutdown flag to true [1]. I suspect that sometimes an InterruptedException may be legitimate and not actually indicate that the event thread must be ultimately destroyed. I'm reassigning the issue to an expert in EventQueue code for further evaluation. [1] http://cr.openjdk.java.net/~ceisserer/7081670/webrev_full.05/src/share/classes/java/awt/EventDispatchThread.java.sdiff.html
18-04-2012
EVALUATION Either 7081670 (most likely) or 7122796 (less likely) could cause this regression.
18-04-2012
EVALUATION Since the bug is reproducible starting with 7u4b06, 7158135 should be unrelated to the issue. Removing it from See Also.
18-04-2012
EVALUATION Anthony please complete evaluation and pass it to resp.eng of 7158135
18-04-2012
EVALUATION It seems that there was no changes in the AWT area for 7u4b20 that could possibly cause this issue. Note that the issue is reproducible on all platforms. From all the fixes integrated into 7u4b20 it looks like 7158135 is likely the cause.
17-04-2012