Current Behaviour

When I exit Minecraft, as in, clicking the Quit Game button after exiting a world, the client hangs, forcing me to pull the plug.
Even though the window closes, the actual java program remains open in the background, as indicated by the launcher I use.

This problem only occurs when the mod is installed and enabled on the instance, and doesn't happen with any other mod.

I've waited for it to close.
As I write this, it's been about half-an-hour since I exited the control instance I created.

Expected Behaviour

Usually, the client just shuts down as normal.

Screenshots

The console log usually stops around the render/threads area.

Reproduction Steps

1. Open a Minecraft Fabric Client with Controlify, YACL, and Fabric API installed.
   a. This works on Quilt and it's Fabric API as well.
2. Load a world, then exit.
   a. I'm unsure if there's a specific time-frame the world needs to be loaded for.
   b. If you simply booted Minecraft, and then just exited, this problem will not occur.
3. Exit the client.
   a. However, it sometimes will close proper randomly, even though a world was loaded and exited? It seems to fail with an ~90% rate from my experience.

Logs

No response

Mod Version

1.4.6+1.20 (On Minecraft 1.20.1)

Controller

No response

Bluetooth

• Yes

Operating System

Linux/SteamOS

ARM

• Yes

Additional Information

It may be a problem with just this launcher and the mod, but I'm not sure.

Just to make sure...

• I have made sure I am using the latest version of Controlify for the latest version of Minecraft.
• I have made sure there are no other issues describing the same problem on the issue tracker.

I can't repeat this, however I have one idea as to maybe why. Give the github actions build I'm about to send a go and let me know.

I also encountered this issue while diagnosing #137 - game often hangs up on [Render thread/INFO]: Stopping! when closing the game. The window itself will close, but the process will hang indefinitely.
The issue seems to be NVIDIA's threaded optimization, which likes to cause lots of weird issues with Minecraft[0]

Reproduction Steps:

1. Start the game
2. Go to "Options..." -> "Controls..." -> "Controller Settings..."
3. Go to either "Global Settings" or a connected controller's "Settings"
4. Attempt to close the game

Step 3. guarantees that the game will hang on closing.

@LStone2001 can you confirm steps above 👆 also cause the hang for you?

Affected versions:
In my case issue occurs both with the latest release (1.4.6+1.20) as well as with commit 8d3ce1d which you mentioned above.

Found workarounds:

• environment variable __GL_THREADED_OPTIMIZATIONS=0[1]
• using Sodium 0.5.0 (that is the most recent as of writing)[2]
• switching rendering to AMD GPU or Zink[3] fixes it as well. Intel GPU would probably also fix the issue, but I haven't checked

Details:

In the affected scenario at step 3 the log will output:

[Render thread/INFO]: Generating YACL screen
[Thread-6/INFO]: OpenGL debug message: id=1281, source=API, type=ERROR, severity=HIGH, message='GL_INVALID_VALUE error generated. Invalid texture format.'

A controller's "Settings" button will print the OpenGL debug message line twice, the "Global Settings" button will only print it once.

For reference:

• With threaded optimizations disabled the log message appears the same
• When using AMD GPU or Zink the OGL message is roughly:

[Render thread/INFO]: OpenGL debug message: id=2, source=API, type=ERROR, severity=HIGH, message='GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)'

The OP uses Prism Launcher, while I'm using MultiMC, the former is a fork of a fork of the latter. I highly doubt the issue would be caused by the launcher, but the correlation is worth pointing out, just in case.

Notes:
[0] Issues caused by the threaded optimization: NVIDIA/open-gpu-kernel-modules#522; r/linux_gaming post; own experience: Tall Worlds Mod (for M3L) also glitches out similarly to previous examples; even Optifine team recommends disabling threaded optimizations
[1] To easily use envvars in MMC or Prism, you can place env __GL_THREADED_OPTIMIZATIONS=0 in "Custom Commands" -> "Wrapper command:", either launcher-wide settings or per-instance settings.
[2] Sodium's changelog doesn't explicitly state threaded optimizations, but CaffeineMC/sodium-fabric@8ae68cf goes in depth about it (It says Prism is unaffected, but we don't know if that's the case for Linux as well or only for Windows). For details you can look for "NVIDIA" and "threaded optimization" related commits between CaffeineMC/sodium-fabric@mc1.20-0.4.10...mc1.20.1-0.5.0
[3] Zink can be enabled with __GLX_VENDOR_LIBRARY_NAME=mesa MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink or just zinkrun on Arch if the wrapper package is installed

@TechniKris, thank you so much for your help and information!
Yes, without __GL_THREADED_OPTIMIZATIONS=0 or Sodium 0.5.0, following your steps, the client always hangs.
Disregard my last steps, since we know now that world-loading has nothing to do with it.
Should I edit those steps in the original post? I'm unsure, since I'm new to GitHub.

Also, @isXander, I did also have the issue with the 8d3ce1d commit. Sorry I didn't mention that sooner.
But only under the conditions that made the issue present.

Does this mean that this isn't an issue with Controlify or YACL, and that NVIDIA's drivers are at fault?

Should I edit those steps in the original post?

I don't think it's necessary since this is a short thread and mine are easy to find, but it's up to you.

Does this mean that this isn't an issue with Controlify or YACL, and that NVIDIA's drivers are at fault?

I'm not greatly familiar with how things related to it work under the hood. I'm pretty sure NVIDIA enabled said problematic option by default in the 535 series driver, since these problems hadn't occured before; so yes, I'd put blame on them. Still, the issue can be worked around by mod devs if they wish to do so (like Sodium devs did in the newest release).

Decided to close, since __GL_THREADED_OPTIMIZATIONS caused this and not Controlify or YACL, and they're not the only mods affected by it.

Perhaps there is a way to stop the issue with __GL_THREADED_OPTIMIZATIONS turned on, but it should be turned off anyway.

It would also be out of scope and unexpected behaviour to modify these settings like Sodium does, so you should just rely on Sodium for this.