JDK-4320219 : Timer can causes VM to exit (1.2 onward?)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.3.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2000-03-09
  • Updated: 2000-06-13
  • Resolved: 2000-06-13
Related Reports
Duplicate :  
Description

Name: krT82822			Date: 03/09/2000


9 Mar 2000, eval1127@eng -- this (apprent) problem was reproducible on 1.2.2., 1.2.2-001 and kestrel-rc1,
so I'm not sure how the user saw it only on kestrel.

The problem does NOT occur on 1.1.8 with Swing 1.1.1, but does occur in 1.2 (1.2-V).  I did not test against 1.2.1.

-------------------------

java version "1.3.0rc1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0rc1-T)
Java HotSpot(TM) Client VM (build 1.3.0rc1-S, mixed mode)

I am not sure where the bug is, but it is here somewhere.  The best I can say
is just run the program.  The VM will exit by itself.  Adjust the delay of the
timer and it will behave correctly.

I have an app that does something like this and on 1.3, it just quits every
time, but on 1.2.2 it does just fine.  The sequence of events and the timing of
them is critical to seeing the bug.  If an app would happen to need this
particular sequence, it would just exit...like mine does.

My app dynamically loads jar files and creates a class (that extends
JFrame...hence the JFrame in this sample) which is the application the user
selects.  The timer monitors the loading of the Jar files and brings up a
JFrame that is used similarly to the ProgressBarInputStream.  Here the timer
does nothing since its existence causes the problem, not what it does.


What should happen is this:
1 The program starts.
2 Timer is started
3 Timer fires an event, which for does nothing here, but is critical to the
process.
4 A JFrame is created
5 The frame is displayed.
6 Control is handed over to the GUI just created.
7 Initial method call exits.

What does happen is that 6 completes correctly.  All components in the frame
work.  However step 7 kills the VM, providing step 3 happens in the correct
place.

TIMER_DELAY is 1000.  Set it to 3000 and it will work correctly.

There is a workaround (not using the timer).  Still, to me this looks like it
could be a major problem somewhere and I feel it should be at least examined
before the final release.  Because of this I am placing high on the "Impact on
  User" even though it is not quite a complete show stopper.

--PROGRAM
import javax.swing.*;
import java.awt.event.*;
import java.awt.*;

public final class TimerBug extends Object {
	public final static int TIMER_DELAY = 1000;
	private Timer timer;
	
	public static void main(String argv[]) {
		try  {
			TimerBug app =  new TimerBug();
		}
		catch (Exception e)  {
			System.out.println("Exception!  " + e.getMessage());
		}
	}
	public TimerBug() {
		timer = new Timer(TIMER_DELAY,new ActionListener()  {
			public void actionPerformed(ActionEvent e)  {
				System.out.println("Action");
			}
		});
		timer.setRepeats(false);
		timer.start();
		try  {
			Thread.sleep(2000);
			
			JFrame ff = new JFrame("Hello");
			ff.setSize(100,100);
			ff.getContentPane().add(new JTextField(10));
			ff.show();
			
			Thread.sleep(5000);
			
			System.out.println("Done.");
		}
		catch (Exception e)  {
			System.out.println("Exception: " + e.getClass() + "  " + e.getMessage());
			e.printStackTrace();
		}
	}
}
(Review ID: 101987) 
======================================================================

Comments
WORK AROUND Trigger the creation of the AWT thread earlier on, perhaps by doing a SwingUtilities.invokeLater in your main. scott.violet@eng 2000-06-13
13-06-2000

EVALUATION This was fixed as part of 4030718. What was happening is that the daemon bit was not explicitly being set on the thread the AWT creates so that the AWT thread would inherit the daemon bit from the thread that created it in. And since a daemon thread will not keep the vm from exiting, the vm would exit. In this example, the Thread created by the Timer (actually by the TimerQueue) would end up triggering the creation of the AWT thread, and since the Timer thread is set with daemon mode, the VM could exit after main completed. Here is what Dave says: The bug fix was integrated as part of the fix for 4030718. The EventDispatchThread is now *always* a daemon thread. The AWT is now kept alive by a separate non-daemon thread. scott.violet@eng 2000-06-13
13-06-2000