JDK-6526272 : Java process is not terminating after a display mode change, on WinXP
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-02-18
  • Updated: 2011-01-19
  • Resolved: 2007-02-21
Related Reports
Duplicate :  
JDK-6513421 - Java process does not terminate on closing the Main Application Frame
Description
I am running the attached test on WinXP Prof which has a Nvidia GeForce4 MX4000 (93.71 driver) using JDK7-b02. The application brings up a JTable in FullScreen mode with a list of display modes supported by the system. My current display mode is 1024x768x32. I am choosing a display mode having 8 bit color depth - 960x600x8x72. The display mode changes. Now when I click 'Exit' on the frame, the frame closes but the java process is not terminating even when I press CTRL+C. I have to open the Task Manager to kill the java process.

This is reproducible only on b02 and not reproducible on b01. Not reproducible on JDK6. Not reproducible on a different machine which is having Nvidia GeForce FX5900 with the same driver. 

I ran the application with J2D_TRACE_LEVEL=4 and I have given the output under comments. I have also given the output of CTRL+BREAK at the console. Problem still exists even when I turn off d3d explicitly.

To reproduce, run the attached test and select a 8 bit display mode from the list and click 'Set Display'. Once display mode changes, click 'Exit'. if the java process does not terminate at the console, the bug is reproduced.
Comments
EVALUATION This is regression of 6387273 and fix for 6513421 helps fix the issue.
21-02-2007
EVALUATION Java2D didn't integrate into b02, but awt did. Looking at the stack trace it appears that some hook is running (rather, waiting, probably for the toolkit thread): "AWT-EventQueue-0" prio=6 tid=0x0ae26800 nid=0x530 in Object.wait() [0x0b11f000. .0x0b11fc14] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x02e88908> (a java.lang.Thread) at java.lang.Thread.join(Thread.java:1143) - locked <0x02e88908> (a java.lang.Thread) at java.lang.Thread.join(Thread.java:1196) at java.lang.ApplicationShutdownHooks.run(ApplicationShutdownHooks.java: 79) at java.lang.Shutdown.runHooks(Shutdown.java:89) at java.lang.Shutdown.sequence(Shutdown.java:133) at java.lang.Shutdown.exit(Shutdown.java:178) - locked <0x06aaf500> (a java.lang.Class for java.lang.Shutdown) at java.lang.Runtime.exit(Runtime.java:90) at java.lang.System.exit(System.java:906) at DisplayModeTest.actionPerformed(DisplayModeTest.java:130) I haven't been able to reproduce this on my machine with NV FX5200. This is a dual-cpu system, so it could be that the timings are different. Reassigning to AWT since they have integrated into b02 and this is apparently a regression in b02.
20-02-2007