JDK-6513421 : Java process does not terminate on closing the Main Application Frame
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp,windows_vista
  • CPU: x86
  • Submitted: 2007-01-16
  • 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 b10Fixed
Related Reports
Duplicate :  
JDK-6526272 - Java process is not terminating after a display mode change, on WinXP
Relates :  
JDK-6660258 - Java application stops Windows logout/shutdown (regression in 1.5.0_14)
Relates :  
JDK-6387273 - JDialog makes browsers crash in mustang b59
Description
The attached test has a JFrame wtih setDefaultCloseOperation set to JFrame.EXIT_ON_CLOSE. 
1)Compile the test and and execute the test on Vista 6000 Ultimate 
2)Click on the Close button of the Frame in the Top Right corner. 
Expected Behavior 
The JFrame closes and the java process exits 
Actual Behavior 
The JFrame closes but the java process does not exit, the process ID can still be seen in The task manager. 

I tried with a simple awt frame with a windowListener for closing the window and the same buggy behavior was seen. 

The test and the thread dump for the same are attached to the bug report.

This behavior is specific to Vista and is not occuring on Windows Xp. 
I could trace this back to jdk 7.0 build 02. 
It is not reproducible with 7.0 build 01.
Comments
SUGGESTED FIX <dc158259@sterna: /net/mandriva/export/public/dc158259/ws/jdk7b3/src/windows/native/sun/windows> #sccs diffs -C awt_Toolkit.cpp ------- awt_Toolkit.cpp ------- *** /tmp/sccs.JRairJ Mon Feb 19 13:23:38 2007 --- awt_Toolkit.cpp Mon Feb 19 13:23:35 2007 *************** *** 461,467 **** // new messages will appear as all the windows except toolkit // window are unsubclassed and destroyed MSG msg; ! while (::GetMessage(&msg, tk.m_toolkitHWnd, 0, 0)) { ::TranslateMessage(&msg); ::DispatchMessage(&msg); } --- 461,467 ---- // new messages will appear as all the windows except toolkit // window are unsubclassed and destroyed MSG msg; ! while (::GetMessage(&msg, NULL, 0, 0)) { ::TranslateMessage(&msg); ::DispatchMessage(&msg); }
19-02-2007
EVALUATION We use ::GetMessage(..., tk.m_toolkit_hwnd, ...) to retrieve messages inside nested loop introduced after fix for 6387273. However, WM_QUIT message is thread-level message (not associated with any window) so we will never exit the loop because we retrieve only messages for toolkit window. We may use NULL instead of "tk.m_toolkit_hwnd" as 2nd parameter for GetMessage. In that case GetMessage retrieves messages for any window that belongs to the calling thread and thread messages posted to the calling thread using the PostThreadMessage function. ---------------------------------------- There is a questionable code inside implementation of shutdown. We post WM_AWT_DELETEOBJECT messages after PostQuitMessage() call. It would be more right to post quit message as last message. MSDN tells about PostQuitMessage that "the function simply indicates to the system that the thread is requesting to quit at some time in the future". Also article http://blogs.msdn.com/oldnewthing/archive/2005/11/04/489028.aspx tells about PostQuitMessage that "the system tries not to inject a WM_QUIT message at a "bad time"; instead it waits for things to "settle down" before generating the WM_QUIT message". This is a difference between PostQuitMessage and PostThreadMessage(WM_QUIT). I've checked that PostQuitMessage really waits until next posted messages are processed (i tested it on XP/Vista). So I think that it's OK to keep that code without any changes for safety.
08-02-2007
EVALUATION it's regression of 6387273. After fix for 6387273 the following message loop was added into the awt_Toolkit.Dispose() method. 456 // wait for any messages to be processed, in particular, 457 // all WM_AWT_DELETEOBJECT messages that delete components; no 458 // new messages will appear as all the windows except toolkit 459 // window are unsubclassed and destroyed 460 MSG msg; 461 while (::GetMessage(&msg, tk.m_toolkitHWnd, 0, 0)) { 462 ::TranslateMessage(&msg); 463 ::DispatchMessage(&msg); 464 } We expect that GetMessage retrieves WM_QUIT message that ends the loop. However, WM_QUIT message is not coming on Vista and so we fail to exit the loop.
17-01-2007
EVALUATION I suspect this behavior may be caused by the fix for 6387273. If so, we need to find the difference between WinXP and Vista and correct the fix for 6387273 accordingly.
16-01-2007