JDK-6828273 : javax/swing/system/6799345/TestShutdown.java test fails with RuntimeException.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2009-04-09
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
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 b116Fixed
Related Reports
Relates :  
JDK-6829923 - Test javax/swing/system/6799345/TestShutdown.java fails on X11 platforms
Relates :  
JDK-4248088 - AWT Threads are created in wrong ThreadGroup
Relates :  
JDK-6799345 - JFC demos threw exception in the Java Console when applets are closed
Description
Bug Info
========
The test fails with RuntimeException on solaris 10 sparc and RHEL5.2 platforms.

javax/swing/system/6799345/TestShutdown.java

JDK Info:
=========
java version "1.7.0-internal"
Java(TM) SE Runtime Environment (build 1.7.0-internal-administrator_2009_04_01_1
5_11-b00)
Java HotSpot(TM) Client VM (build 15.0-b03, mixed mode)

Paltforms
==========
OS: Solaris sparc 10 
OS : RHEL 5.2


Exception Details
=================
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
EVALUATION At a first glance, this bug looks pretty strange. Indeed, in the fix for 6799345 I included the check to XToolkit.run(): if (Thread.currentThread().isInterrupted()) { System.err.println("interrupted"); // 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; } } just to cover that particular case of AppContext disposal. Still, an exception is thrown from awtUnlock()... That's strange. The next step is to insert some debug output to the code and try to find what's going. Surprisingly, the very first println discovered a problem. I logged the current thread's ThreadGroup and the current AppContext in two different places: at the beginning of XToolkit.run() and in the beginning of the test. The output was: XToolkit AppContext = sun.awt.AppContext[threadGroup=system] XToolkit ThreadGroup = TestShutdown$TestThreadGroup[name=TTG,maxpri=10] Test AppContext = sun.awt.AppContext[threadGroup=TTG] Test ThreadGroup = TestShutdown$TestThreadGroup[name=TTG,maxpri=10] What looks really, really strange is that XToolkit's thread group is not "system", but "TTG" - thread group created in the test - while its AppContext is "system". However, after some investigation I've found the reason: toolkit is created in TestRunnable (which runs in TTG) before the call to SunToolkit.createAppContext() is completed. That's why toolkit "inherits" AppContext value from the parent thread group. Given that, I see several possible solutions: 1. Lowest-risk fix: correct the test and call Toolkit.getDefaultToolkit() at the very beginning of the main() method. 2. Create the toolkit thread in a system thread group regardless of which thread XToolkit is initialized. In fact we already have the related code in XToolkit ctor: see 'mainTG' local variable which is never used. The fix may be to use mainTG as a thread group for the toolkit thread.
26-06-2009
EVALUATION Assigned to the RE of the bug #6799345
23-06-2009