JDK-8114019 : Mac: closing javafx application with window button takes a while to end java process
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: fx2.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2011-07-13
  • Updated: 2015-06-16
  • Resolved: 2012-01-31
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.
Other
fx2.1Fixed
Related Reports
Blocks :  
JDK-8128180 - Remove workaround on Mac where we are calling System.exit
Duplicate :  
JDK-8116226 - Mac: applications frequently hang after closing them
Relates :  
JDK-8114065 - Mac: need workaround for crash / hang on exit issues
Relates :  
JDK-8116226 - Mac: applications frequently hang after closing them
Description
Closing javafx applications using the widow close button most closes the window but the java process doesn't end for up to 1 minute.

Steps: 
Launch sdk/apps/DisplayShelf.jar from command line with java -jar DisplayShelf.jar 
Use the window close button to end the app and the java process remains.
Comments
verified in promotion build 17
21-03-2012
Let's keep this one open and close RT-19030
26-01-2012
Duplicate of RT-19030
26-01-2012
This exactly suggests that the app waits till the event loop is spun at least one more time by means of processing an input event. Please see my comment above - perhaps we should simply send a no-op synthetic event after calling [NSApp stop].
26-01-2012
Easily reproducible: after Window close button is clicked, the application hangs around until either mouse is moved or key is pressed - puzzling.
25-01-2012
Raise priority to critical to match that of RT-17777. Note that until RT-19030 and RT-19031 are fixed, this bug may not manifest itself.
19-01-2012
The issue has been workarounded with RT-15601. A proper fix should be delivered in Presidio Updates.
12-08-2011
The spec for NSApplication stop: states: ************************************************************************ This method notifies the application that you want to exit the current run loop as soon as it finishes processing the current NSEvent object. This method does not forcibly exit the current run loop. Instead it sets a flag that the application checks only after it finishes dispatching an actual event object. For example, you could call this method from an action method responding to a button click or from one of the many methods defined by the NSResponder class. However, calling this method from a timer or run-loop observer routine would not stop the run loop because they do not result in the posting of an NSEvent object. If you call this method from an event handler running in your main run loop, the application object exits out of the run method, thereby returning control to the main() function. If you call this method from within a modal event loop, it will exit the modal loop instead of the main event loop. ************************************************************************ So perhaps it makes sense to send a dummy event right after MacApplication._finishTerminating() calls [NSApp stop]; to make sure the [NSApp run] has a chance to check this flag and terminate the event loop.
10-08-2011
Chien and I took a look at this, and it looks like the JavaFX application, which is also the Cocoa thread on Mac, isn't terminating even though the QuantumToolkit is calling Application.terminate().
14-07-2011
Here is a complete stack dump of a hang program on closing: 2011-07-14 09:37:59 Full thread dump Java HotSpot(TM) 64-Bit Server VM (19.1-b02-334 mixed mode): "Attach Listener" daemon prio=9 tid=101801800 nid=0x11f215000 waiting on condition [00000000] java.lang.Thread.State: RUNNABLE "DestroyJavaVM" prio=5 tid=102928000 nid=0x100501000 waiting on condition [00000000] java.lang.Thread.State: RUNNABLE "Disposer" daemon prio=10 tid=101ad4800 nid=0x11e337000 in Object.wait() [11e336000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <7f42b0100> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) - locked <7f42b0100> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134) at com.sun.glass.utils.Disposer.run(Disposer.java:64) at java.lang.Thread.run(Thread.java:680) "JavaFX Application Thread" prio=5 tid=102abd800 nid=0x7fff70d1aca0 runnable [00000000] java.lang.Thread.State: RUNNABLE "Low Memory Detector" daemon prio=5 tid=102825800 nid=0x109f13000 runnable [00000000] java.lang.Thread.State: RUNNABLE "CompilerThread1" daemon prio=9 tid=102824800 nid=0x109e10000 waiting on condition [00000000] java.lang.Thread.State: RUNNABLE "CompilerThread0" daemon prio=9 tid=102824000 nid=0x109d0d000 waiting on condition [00000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=9 tid=102823000 nid=0x109c0a000 runnable [00000000] java.lang.Thread.State: RUNNABLE "Surrogate Locker Thread (CMS)" daemon prio=5 tid=102822800 nid=0x109b07000 waiting on condition [00000000] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=8 tid=102819800 nid=0x1097fc000 in Object.wait() [1097fb000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <7f42b0ba0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) - locked <7f42b0ba0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=10 tid=102819000 nid=0x1096f9000 in Object.wait() [1096f8000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <7f42b0338> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:485) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <7f42b0338> (a java.lang.ref.Reference$Lock) "VM Thread" prio=9 tid=102814000 nid=0x1095f6000 runnable "Gang worker#0 (Parallel GC Threads)" prio=9 tid=101802800 nid=0x102201000 runnable "Gang worker#1 (Parallel GC Threads)" prio=9 tid=101803800 nid=0x102304000 runnable "Concurrent Mark-Sweep GC Thread" prio=9 tid=10184e000 nid=0x109302000 runnable "VM Periodic Task Thread" prio=10 tid=101892800 nid=0x10a016000 waiting on condition "Exception Catcher Thread" prio=10 tid=101802000 nid=0x10176a000 runnable JNI global references: 1797
14-07-2011
We saw this once or twice during our integration testing, but were getting the intermittent "crash on exit" problem often enough on that system that we weren't able to get a stack trace. I suspect that this is a latent bug in the system exposed by my changes to the app lifecycle (RT-11146). It would be helpful if we could get a thread dump from "jstack" when this happens.
14-07-2011