Are there advanced troubleshooting techniques I can try to debug a JavaFX process that hangs on close?

So this one is a bit of a noodle scratcher, and I was wondering if anyone out there has ideas on things I might be able to try to get to the bottom of this.

JRE/JDK is 1.8.0_251, running on Windows 10. Application is a JavaFX application launched using launch4j.

Sometimes when I exit the application, the JVM will not shut down. Instead, I have a process stuck in Task Manager until I explicitly close it. It used to be intermittent, now it's almost constant.

I suspect I've got a user thread stuck which is blocking the application from closing. However, I have not been able to collect a useful thread dump to see if I can identify where the thread is being created.

When I run into this situation, I identify the process ID via tasklist / wmic (JMC doesn't see the process), then I try to run jstack against it:

"jstack -F" works, but removes all helpful information like thread names or type of threads (daemon / user). None of the threads contain any references to my code.
"jstack -l" used to work, and I saw two affected threads named "pool-#-thread-#" that were not daemon threads but then I had to install the _251 JDK after a JRE update was pushed to my machine and since then, it just hangs forever. (I've left it to run for hours, no change)

If I could get the ability to run jstack -l back, it'd go a long way towards helping me identify the Executor pool causing this. The application spawns a few different pools, and the few I know of all explicitly set the daemon flag on threads they generate.

Interestingly enough, I have a similar problem when running the application from Eclipse. None of the other people on my team can reproduce this problem, and this problem only started after I had received a replacement laptop. You'd think if there was a sticky user thread, other people would see the same problem. This makes me think there might be something environmental/hardware involved or that I might be triggering a JRE bug.

Has anyone out there successfully troubleshooted an issue like this where jstack is hanging? Any tricks for getting a thread dump when the application fails to shut down?

Solution

So, after poking around at this again for some time, I've at least made some progress and have a good idea what is causing the problem, though not necessarily how to solve it just yet.

The thread dump acquired via jstack -F contained a tell-tale line that I had missed having been focused on the fact that there were no thread names / daemon status in the output received:

Thread 22: (state = IN_NATIVE)
- com.sun.prism.d3d.D3DPipeline.nDispose() u/bci=0 (Interpreted frame)
- com.sun.prism.d3d.D3DPipeline.dispose() u/bci=49, line=164 (Interpreted frame)
- com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.cleanup() u/bci=9, line=118 (Interpreted frame)
- com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run() u/bci=14, line=127 (Interpreted frame)
- java.lang.Thread.run() u/bci=11 (Interpreted frame)

Having done Java support for years, I know that the hardware accelerated Java UI can have troubles with certain graphics cards / drivers. So I tried disabling the d3d renderer using the -Dsun.java2d.d3d=falseflag on the JVM. Wasn't able to reproduce the hang.

Of course, just disabling hardware acceleration is not the ideal solution for me, so I've been delving deeper into troubleshooting the issue. The call stack above led me to learn about the -Dprism.verbose flag which gave me more information about what card was being used. (Internal Intel GPU rather than my external GPU)

I've since tried upgrading the drivers, and will look into how I might be able to switch prism from using the intel chipset to my dedicated GPU and see if that resolves the problem. But at the very least, I do have the option to disable the d3d acceleration completely.