-
Bug
-
Resolution: Duplicate
-
P4
-
None
-
1.3.1
-
x86
-
windows_nt, windows_2000
Name: gm110360 Date: 07/09/2002
FULL PRODUCT VERSION :
java version "1.3.1_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03)
Java HotSpot(TM) Client VM (build 1.3.1_03-b03, mixed mode)
FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]
A DESCRIPTION OF THE PROBLEM :
Calling setVisible on a frame from within a Shutdown hook
will result in a deadlock and the JVM not being able to be
shutdown.
Here is an example application to demonstrate the problem.
The flag at the top enables the only workaround that I am
aware of.
<source in source section>
Doing a thread dump when in this state results in the
following for the shutdown hook thread:
---
"shutdown_hook" prio=5 tid=0x8a84c78 nid=0xb94 runnable
[0xb59f000..0xb59fdbc]
at sun.awt.windows.WComponentPeer.hide(Native Method)
at java.awt.Component.hide(Unknown Source)
at java.awt.Window.hide(Unknown Source)
at java.awt.Component.show(Unknown Source)
at java.awt.Component.setVisible(Unknown Source)
at AWTDeadlock.shutdown(AWTDeadlock.java:43)
at AWTDeadlock.access$000(AWTDeadlock.java:3)
at AWTDeadlock$1.run(AWTDeadlock.java:22)
---
This workaround is not very clean and is difficult to
implement in large systems. How should the shutdown of
swing be handled?
Cheers,
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile the above class
2. java -classpath ./ AWTDeadlock
3. hit CTRL-C from the console when the frame is visible.
4. the app will not shutdown.
5. hit CTRL-BREAK to get the thread dump.
EXPECTED VERSUS ACTUAL BEHAVIOR :
I get the following output:
---
C:\...>java -classpath ./ AWTDeadlock
shutdownHook start
AA
< JVM hung here >
---
Should get:
---
C:\...>java -classpath ./ AWTDeadlock
shutdownHook start
AA
AB
AC
shutdownHook end
C:\...>
---
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.awt.Frame;
public class AWTDeadlock extends Frame {
private static final boolean WORKAROUND = false;
private Thread m_hook;
private AWTDeadlock() {
super( "AWTDeadlock Example" );
setSize( 400, 100 );
setLocation( 50, 50 );
show();
// Add a shutdown hook to trap CTRL-C events.
m_hook = new Thread( "shutdown_hook" )
{
public void run()
{
System.out.println( "shutdownHook start");
shutdown();
System.out.println( "shutdownHook end");
}
};
Runtime.getRuntime().addShutdownHook( m_hook );
}
private void shutdown() {
if ( WORKAROUND ) {
// This code will workaround the problem
if ( Thread.currentThread() != m_hook ) {
System.out.println(" BA");
setVisible(false);
System.out.println(" BA");
dispose();
System.out.println(" BA");
}
} else {
// This code will show the deadlock.
System.out.println(" AA");
setVisible(false);
System.out.println(" AB");
dispose();
System.out.println(" AC");
}
}
public static void main(String[] args) {
new AWTDeadlock();
}
}
---------- END SOURCE ----------
CUSTOMER WORKAROUND :
See source code.
(Review ID: 147282)
======================================================================
FULL PRODUCT VERSION :
java version "1.3.1_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03)
Java HotSpot(TM) Client VM (build 1.3.1_03-b03, mixed mode)
FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]
A DESCRIPTION OF THE PROBLEM :
Calling setVisible on a frame from within a Shutdown hook
will result in a deadlock and the JVM not being able to be
shutdown.
Here is an example application to demonstrate the problem.
The flag at the top enables the only workaround that I am
aware of.
<source in source section>
Doing a thread dump when in this state results in the
following for the shutdown hook thread:
---
"shutdown_hook" prio=5 tid=0x8a84c78 nid=0xb94 runnable
[0xb59f000..0xb59fdbc]
at sun.awt.windows.WComponentPeer.hide(Native Method)
at java.awt.Component.hide(Unknown Source)
at java.awt.Window.hide(Unknown Source)
at java.awt.Component.show(Unknown Source)
at java.awt.Component.setVisible(Unknown Source)
at AWTDeadlock.shutdown(AWTDeadlock.java:43)
at AWTDeadlock.access$000(AWTDeadlock.java:3)
at AWTDeadlock$1.run(AWTDeadlock.java:22)
---
This workaround is not very clean and is difficult to
implement in large systems. How should the shutdown of
swing be handled?
Cheers,
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile the above class
2. java -classpath ./ AWTDeadlock
3. hit CTRL-C from the console when the frame is visible.
4. the app will not shutdown.
5. hit CTRL-BREAK to get the thread dump.
EXPECTED VERSUS ACTUAL BEHAVIOR :
I get the following output:
---
C:\...>java -classpath ./ AWTDeadlock
shutdownHook start
AA
< JVM hung here >
---
Should get:
---
C:\...>java -classpath ./ AWTDeadlock
shutdownHook start
AA
AB
AC
shutdownHook end
C:\...>
---
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.awt.Frame;
public class AWTDeadlock extends Frame {
private static final boolean WORKAROUND = false;
private Thread m_hook;
private AWTDeadlock() {
super( "AWTDeadlock Example" );
setSize( 400, 100 );
setLocation( 50, 50 );
show();
// Add a shutdown hook to trap CTRL-C events.
m_hook = new Thread( "shutdown_hook" )
{
public void run()
{
System.out.println( "shutdownHook start");
shutdown();
System.out.println( "shutdownHook end");
}
};
Runtime.getRuntime().addShutdownHook( m_hook );
}
private void shutdown() {
if ( WORKAROUND ) {
// This code will workaround the problem
if ( Thread.currentThread() != m_hook ) {
System.out.println(" BA");
setVisible(false);
System.out.println(" BA");
dispose();
System.out.println(" BA");
}
} else {
// This code will show the deadlock.
System.out.println(" AA");
setVisible(false);
System.out.println(" AB");
dispose();
System.out.println(" AC");
}
}
public static void main(String[] args) {
new AWTDeadlock();
}
}
---------- END SOURCE ----------
CUSTOMER WORKAROUND :
See source code.
(Review ID: 147282)
======================================================================
- duplicates
-
JDK-6261550 (spec) Runtime.addShutdownHook should warn against depending upon other threads
- Resolved