Skip to content

Fix thread leak hanging shutdown on 26.2#2975

Draft
TauCu wants to merge 1 commit into
EngineHub:version/7.4.xfrom
TauCu:fix/sessionmgr_thread_leak
Draft

Fix thread leak hanging shutdown on 26.2#2975
TauCu wants to merge 1 commit into
EngineHub:version/7.4.xfrom
TauCu:fix/sessionmgr_thread_leak

Conversation

@TauCu

@TauCu TauCu commented Jun 20, 2026

Copy link
Copy Markdown

Since 26.2, the client (and possibly server?) waits for threads to exit before closing. Crashing after a short time.
This pull fixes a bug where SessionManager didn't properly shut down.

The game crashed: client shutdown from post-main
Error: java.lang.Error: Watchdog (Client shutdown from post-main)

Cause:

  1. SessionManager is initialized at client start but only shutdown at server shutdown. If the client never opens a world, SessionManager#unload is never called.
  2. SessionManager#unload does not shutdown the executor, causing the client to time out and crash when waiting for it to exit anyway.

Fixes:

  • Move SessionManager to PlatformManager and make it use platform ready/unready events.
  • Fix SessionManager#unload canceling timer and no longer auto-saving after quitting a world.
  • Remove timer and use a single ScheduledExecutorService with a single virtual thread.
  • Make sure executor shuts down on SessionManager#unload

Draft reason:
I'm making this as a draft for now as I'm not entirely sure what consequences of making the session manager dependent on Ready/Unready event are.
I smoketested it on all platforms but that doesn't really say much.
Could someone with some knowledge of when SessionManager is supposed to be available chime in?

The only other thing I want some insight on was the effects of ScheduledExecutorService using an unbounded DelayedWorkQueue and the original used a bounded-queue of 5. Unless I'm missing something I don't think this will cause issues?

Move Session Manager to PlatformManager and shut it down with unready event.
Fix SessionManager#unload canceling timer, which prevents automatic saving of sessions after quitting a singleplayer world once.
@me4502

me4502 commented Jun 20, 2026

Copy link
Copy Markdown
Member

I'm a bit confused by this PR, is this specifically an issue on a certain platform? I've been using Fabric with WorldEdit installed while joining a server to test the Bukkit version of WorldEdit on 26.2 and never hit this issue, and from a quick test of just launching the game in both NF & Fabric to the menu and closing it I cannot reproduce any issues.

Can you please elaborate on what about 26.2 has caused this problem?

@TauCu

TauCu commented Jun 20, 2026

Copy link
Copy Markdown
Author

Are you using the normal launcher? The worldedit-fabric:run_client config also seems to do it.
I'm running Windows 10 LTSC, builtin JRE for the launcher, Temurin-25.0.3+9 for Intellij/Environment.

This is the crash: https://pastebin.com/9kgejvG0
This is a video of the crash: enc.webm

When using fix/sessionmgr_thread_leak branch there is no crash.

I also did some more testing and it seems the executor service doesn't seem to cause a crash, but the timer is. Either way, they should be shutdown cleanly.

@Athar42

Athar42 commented Jun 24, 2026

Copy link
Copy Markdown

I can confirm this.
Same "long" mod list on 26.1.2 (and prior releases), no issues, but the beta release for 26.2 did cause the game to generate a crash log on game shutdown (the game seems to close gracefully, but it hang in the background like stated here).

On my end, as soon as the mod is loaded, starting and closing it right away trigger that issue (no need to go anywhere in the game, directly from the start menu).

Edit : Can confirm after building this commit release, the game close without issue (but didn't test further the mod tho)
image

@me4502

me4502 commented Jun 25, 2026

Copy link
Copy Markdown
Member

So I did some investigation after some information from someone in the Discord helped me actually reproduce this. From what I can tell, the actual "hang then crash on the client on exit" is not caused by WorldEdit, but the copy of Fabric API that we bundle in jar-in-jar. I was able to replicate the issue without WorldEdit, but the contents of META-INF/jars from WorldEdit's jar file in the mods folder instead.

I was also only able to replicate it by putting an old GPU into my machine (GTX 1080) and setting the graphics API to Vulkan. OpenGL did not lead to this crash, and neither did my typical GPU (RTX 5070).

It seems like this is a bug in Fabric, rather than in WorldEdit itself, especially as WorldEdit runs on the logical server and doesn't interface with graphical APIs at all.

Whether there are improvements we can make to the lifecycle or not is a different question though, but that seems unrelated to the crash people are reporting.

Edit: Crash report without WorldEdit installed if it's helpful for anyone else, https://mclo.gs/b4afEZM

Current theory is there's some quirk with specifically this old version of Vulkan, but unsure why it triggers this issue, as nothing else is really making sense.

@Athar42

Athar42 commented Jun 25, 2026

Copy link
Copy Markdown

Yours seems like a different issue, as ours (OP and I) clearly state this kind of blocking task :
""WorldEdit Session Manager" prio=5 Id=71 TIMED_WAITING on java.util.TaskQueue@444da2de"

And I can't reproduce that crash as soon as I remove WorldEdit so... (and still using OpenGL and with a RTX4080

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants