process does not quit when game closes, some threads still live

[keturn]

I've just quit Terasology by the exit button on the main menu, and the window closed but the java process did not end.

While I was typing this up, it eventually closed, about eight minutes after initially logging the "Shutting down Terasology" message.

Discovered in the process of investigating MovingBlocks/TerasologyLauncher#563

Log details and game version

Release 36. Or 81. Or 3.2.0. Which of these numbers is the important one? See attached Terasology.log

Also:
Thread Dump

Computer details

Linux, JDK is liberica-11.

[keturn]

Most of the threads in that thread dump are marked as daemon threads, which means they're not supposed to be able to prevent the jvm from shutting down. One of them is the DestroyJavaVM thread in state RUNNABLE, I'm guessing that one is not the problem.

The other is pool-3-thread-1:

"pool-3-thread-1" #43 prio=5 os_prio=0 cpu=86.44ms elapsed=225.54s tid=0x00007f02e5a6e800 nid=0xe6856 waiting on condition  [0x00007f01c9dee000]
   java.lang.Thread.State: WAITING (parking)
        at jdk.internal.misc.Unsafe.park([email protected]/Native Method)
        - parking to wait for  <0x000000071c3c8dc0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park([email protected]/LockSupport.java:194)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await([email protected]/AbstractQueuedSynchronizer.java:2081)
        at java.util.concurrent.LinkedBlockingQueue.take([email protected]/LinkedBlockingQueue.java:433)
        at java.util.concurrent.ThreadPoolExecutor.getTask([email protected]/ThreadPoolExecutor.java:1054)
        at java.util.concurrent.ThreadPoolExecutor.runWorker([email protected]/ThreadPoolExecutor.java:1114)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run([email protected]/ThreadPoolExecutor.java:628)
        at java.lang.Thread.run([email protected]/Thread.java:834)

   Locked ownable synchronizers:
        - None

Heck if I know what to make of that.

[keturn]

The other thing I noticed while I had VisualVM attached is that the heap size was steadily going up during this. From 250 MB to 300 MB over five minutes. Which wouldn't be so weird, except that it's during shutdown.

[Cervator]

So traditionally this has been a prickly area with lots of bugs. Just dig through open and closed issues (and closed PRs) for a nice amount of graceful shutdown issues. In at least some cases it seems related to the game starting a thing and leaving it open (well, okay, put that way that probably describes everything), like entering a network context but then crashing out and bypassing some needed cleanup.

I've looked at a thread dump or two myself, but also don't really know how to make heads and tails of it. It happens intermittently enough (and gets better and worse over time) to where it is tricky to just nail down some specific reproducible cases we can examine more closely to identify and fix the responsible bugs.

Throwing a profiler in the mix is a huge pool of potential for helping fix both these kinds of issues, other assorted bugs, and our leaks, of which there are definitely several, but in much the same kind of situation.

[DarkWeird]

Classic problem, resource not freed.
This thread pool created without thread-naming.