JDK-6829923 : Test javax/swing/system/6799345/TestShutdown.java fails on X11 platforms
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2009-04-14
  • Updated: 2011-01-19
  • Resolved: 2009-04-29
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
7 b57Fixed
Related Reports
Relates :  
JDK-6799345 - JFC demos threw exception in the Java Console when applets are closed
Relates :  
JDK-6828273 - javax/swing/system/6799345/TestShutdown.java test fails with RuntimeException.
Relates :  
JDK-6627356 - Try to preserve Lock invariants even when faced with Thread.stop
Description
Regression test javax/swing/system/6799345/TestShutdown.java fails on Linux/Solaris systems with the following message:

AWT blocker activation interrupted:
java.lang.InterruptedException
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:502)
	at sun.awt.AWTAutoShutdown.activateBlockerThread(AWTAutoShutdown.java:331)
	at sun.awt.AWTAutoShutdown.notifyThreadBusy(AWTAutoShutdown.java:168)
	at java.awt.EventQueue.initDispatchThread(EventQueue.java:847)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:170)
Test FAILED: an exception is caught in the target thread group on thread AWT-XAWT
java.lang.IllegalMonitorStateException
	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:155)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1193)
	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:459)
	at sun.awt.SunToolkit.awtUnlock(SunToolkit.java:277)
	at sun.awt.X11.XToolkit.run(XToolkit.java:634)
	at sun.awt.X11.XToolkit.run(XToolkit.java:561)
	at java.lang.Thread.run(Thread.java:717)
java.lang.RuntimeException: Test FAILED: some exceptions occurred
	at TestShutdown.main(TestShutdown.java:69)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:623)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:717)
Comments
SUGGESTED FIX src/solaris/classes/sun/awt/X11/XToolkit.java @@ -563,10 +563,21 @@ public void run(boolean loop) { XEvent ev = new XEvent(); while(true) { + // Fix for 6829923: we should gracefully handle toolkit thread interruption + if (Thread.currentThread().isInterrupted()) { + // We expect interruption from the AppContext.dispose() method only. + // If the thread is interrupted from another place, let's skip it + // for compatibility reasons. Probably some time later we'll remove + // the check for AppContext.isDisposed() and will unconditionally + // break the loop here. + if (AppContext.getAppContext().isDisposed()) { + break; + } + } awtLock(); try { if (loop == SECONDARY_LOOP) { // In the secondary loop we may have already aquired awt_lock // several times, so waitForEvents() might be unable to release
15-04-2009
EVALUATION The stack trace from the test shows the exception is coming from XToolkit.run(boolean) method, when awtUnlock() is called in 'finally' clause. However, it's not clear why the thread (XAWT toolkit thread) suddenly loses the lock ownership... I remember another issue with AppContext disposal, it's related to 6627356. That's why my first guess was to check when awtUnlock() really throws an exception - and I found it to be ThreadGroup.stop() called from AppContext.dispose(). However, prior to the stop() call we try to shutdown all the threads in a more graceful way by calling ThreadGroup.interrupt() - but it's completely ignored by XToolkit. The fix is to check for the thread interruption status in XToolkit message loop - see Suggested Fix for details. It's not perfect, though, as a single loop iteration may take more time than the delay between interrupt() and stop(), but still helps in most of the cases.
15-04-2009
EVALUATION This is not a regression of 6799345, but an issue we've had for years in XAWT. The problem is that we don't handle interruption for AWT-XAWT thread, which occurs (for example) when the system AppContext is being disposed.
14-04-2009