JDK-8238505 : [macOS] Intermittent deadlock on exit in MacTimer
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8u212,jfx15
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: os_x
  • Submitted: 2020-02-04
  • Updated: 2025-01-14
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
jfx25Unresolved
Related Reports
Relates :  
JDK-8340405 - JavaFX shutdown hook can hang preventing app from exiting
Relates :  
JDK-8328629 - JUnit test without a timeout value can hang indefinitely
Relates :  
JDK-8189926 - [Mac] Pulse timer should pause when idle
Description
I got a one-time deadlock on exit.

The PulseTimer-CVDisplayLink thread was calling Timer::pause at the same time the Glass/Prism Shutdown Hook thread was calling Timer::stop. The pause method was added as part of the fix for JDK-8189926.

I note that this particular deadlock can only happen if the application calls System.exit without first calling Platform::exit, since that is the only case in which the shutdown hook is run.

Here is the relevant information from the threads in question:

"PulseTimer-CVDisplayLink thread" #15 daemon prio=5 os_prio=31 cpu=26.53ms elapsed=540.17s tid=0x00007f8cc1454000 nid=0x14703 waiting for monitor entry  [0x00007000079f1000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at com.sun.glass.ui.Timer.pause(javafx.graphics/Timer.java:142)
	- waiting to lock <0x000000070eb0ee70> (a com.sun.glass.ui.mac.MacTimer)
	at com.sun.javafx.tk.quantum.QuantumToolkit.pauseTimer(javafx.graphics/QuantumToolkit.java:502)
	- locked <0x000000070eee9fe8> (a com.sun.javafx.tk.quantum.QuantumToolkit)
	at com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(javafx.graphics/QuantumToolkit.java:489)
	at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$12(javafx.graphics/QuantumToolkit.java:345)
	at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$122/0x0000000800b8b840.run(javafx.graphics/Unknown Source)


"Glass/Prism Shutdown Hook" #12 prio=5 os_prio=31 cpu=1.81ms elapsed=539.93s tid=0x00007f8cc0b7e000 nid=0xdc0f runnable  [0x0000700007d7d000]
   java.lang.Thread.State: RUNNABLE
	at com.sun.glass.ui.mac.MacTimer._stop(javafx.graphics/Native Method)
	at com.sun.glass.ui.Timer.stop(javafx.graphics/Timer.java:131)
	- locked <0x000000070eb0ee70> (a com.sun.glass.ui.mac.MacTimer)
	at com.sun.javafx.tk.quantum.QuantumToolkit.dispose(javafx.graphics/QuantumToolkit.java:842)
	at com.sun.javafx.tk.quantum.QuantumToolkit$1.run(javafx.graphics/QuantumToolkit.java:253)

The complete stack dump is attached.
Comments
> I would suggest to keep this as P3 OK. > because I think it is typical for the app developers to call System.exit() rather than Platform.exit() Sadly, you are probably right. Even though we recommend calling Platform.exit first, we know that many applications don't, and we need to ensure that it works robustly when System.exit is called directly. I'll write up a longer evaluation later, but two possible thoughts on how to approach this: 1. Call Plataform.exit() from our ShutdownHook (possibly followed by a call to dispose if there is a case where Platform.exit doesn't). This was discussed (10 years ago!) in JDK-8095201 as a better long term solution than just calling dispose from the shutdown hook, but it is more intrusive, and there might be problematic cases. If it works and solves the deadlock, this might be the best solution. 2. Stop the Timer on the Timer thread (if possible), or otherwise ensure that we don't call Timer.stop while the Timer thread is trying to call Timer.pause.
20-09-2024
I would suggest to keep this as P3 because I think it is typical for the app developers to call System.exit() rather than Platform.exit()
20-09-2024
While I was testing the fix for JDK-8328629 (default timeout for JUnit 5 tests), I ran into this again. I attached thread-dump2.log with thread stack dump. By itself, a test timeout is ineffective, since when the deadlock happens, one of the threads is running a shutdown hook. I filed JDK-8340405 to fix our shutdown hook logic to not hang indefinitely in a shutdown hook. That, along with the default timeout being added by JDK-8328629, will make the deadlock tracked by *this* bug less severe. Once I integrate both of the other fixes, we can lower the priority of this deadlock back to P4.
18-09-2024
We are seeing this more frequently on our nightly and on-demand headful test jobs.
20-03-2024
I ran into this a couple more times today during local testing. Bumping to P3.
26-02-2020
I have only seen this once, and the code in question in the shutdown hook is only called when System.exit is called, so I made this a P4. If it can be reproduced with some regularity we can bump it to P3.
04-02-2020