1.17.1 Vanilla – java.lang.reflect.InvocationTargetException / Could not initialize class org.lwjgl.glfw.GLFW

[edgarogh]

Operating System

Linux

Description of bug

When trying to start a 1.17.1 instance that I just created to try, the game crashes with the following stack trace:

[17:41:20] [Render thread/INFO]: Setting user: MrAnimaM
[17:41:20] [Render thread/INFO]: [STDERR]: Failed to start Minecraft:
[17:41:20] [Render thread/INFO]: [STDERR]: java.lang.reflect.InvocationTargetException
[17:41:20] [Render thread/INFO]: [STDERR]: 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[17:41:20] [Render thread/INFO]: [STDERR]: 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
[17:41:20] [Render thread/INFO]: [STDERR]: 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[17:41:20] [Render thread/INFO]: [STDERR]: 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
[17:41:20] [Render thread/INFO]: [STDERR]: 	at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:210)
[17:41:20] [Render thread/INFO]: [STDERR]: 	at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:245)
[17:41:20] [Render thread/INFO]: [STDERR]: 	at org.multimc.EntryPoint.listen(EntryPoint.java:143)
[17:41:20] [Render thread/INFO]: [STDERR]: 	at org.multimc.EntryPoint.main(EntryPoint.java:34)
[17:41:20] [Render thread/INFO]: [STDERR]: Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.lwjgl.glfw.GLFW
[17:41:20] [Render thread/INFO]: [STDERR]: 	at com.mojang.blaze3d.platform.GLX.getOpenGLVersionString(SourceFile:35)
[17:41:20] [Render thread/INFO]: [STDERR]: 	at com.mojang.blaze3d.systems.RenderSystem.getApiDescription(SourceFile:770)
[17:41:20] [Render thread/INFO]: [STDERR]: 	at ac.a(SourceFile:65)
[17:41:20] [Render thread/INFO]: [STDERR]: 	at dvp.a(SourceFile:2418)
[17:41:20] [Render thread/INFO]: [STDERR]: 	at dvp.a(SourceFile:2412)
[17:41:20] [Render thread/INFO]: [STDERR]: 	at net.minecraft.client.main.Main.main(SourceFile:187)
[17:41:20] [Render thread/INFO]: [STDERR]: 	... 8 more
[17:41:20] [Render thread/INFO]: [STDOUT]: Exiting with -1

full version here: https://paste.ee/p/4gAUv

Steps to reproduce

• Create a 1.17.1 instance on MultiMC 0.6.13-2519
• This version requires a version of java ≥16. Trying to start it with a lower version will result in an error telling us to use a more recent version of Java.
• Select openjdk16 or oracle jdk 16 (both don't work)
• Launch the game
• I also tried to use the exact bundled java binary that is shipped with the official Minecraft launcher (inside .minecraft/runtime) and it still doesn't work

Suspected cause

I have no idea, the stack trace is truncated and I don't know why the "GLFW" class wouldn't load. I have a lot of MultiMC instances, ranging from 1.8 to 1.16.*, modded and vanilla, and they all work (on openjdk8 though).

This issue is unique

• I have searched the issue tracker and did not find an issue describing my bug.

[lesterlo]

I have this problem on macOS 12 too.
This error prompt when I using openJDK 17 and openJDK 11. Both of them are not working and having the same glfw error.

To solve this problem, I use brew to install adoptopenjdk 16.

[edgarogh]

I'm away from home and cannot test on the same computer as before, but I'll take a look ! Thank you for your potential solution.

[jamierocks]

Are you running with aarch64 at all?

[lesterlo]

@jamierocks For Me, Yes. I am running the MultiMC on Apple Silicon

[edgarogh]

@jamierocks And for me, I have a Ryzen amd64, nothing out of the ordinary. The laptop I'm using right now has the exact same OS and same architecture as my desktop computer that I don't have access to right now, and 1.17.1 works on MultiMC here... I'll try to do some research on my own (by comparing everything I can) once I have access to my desktop, hoping I can find something.

Since the problem is related to GLFW, could it be also linked to graphics driver though ? or it's strictly a Java problem ? Because my desktop computer – where it crashes – has an AMD GPU with the amdgpu Linux drivers and my laptop ­– where things work – has an nVidia GPU with the closed-source Linux drivers. I'm wondering if the class-loading problem could be somehow caused by a missing shared library of some sort.
I don't know much about GPUs and GPU drivers overall, and what precisely they are responsible for. Shared libraries might have nothing to do with them...

[kb-1000]

So, this doesn't quite look easy to debug, since something eats the actual exception that caused the GLFW class to fail loading.
Are there any other differences between the computer where it works and the computer where it doesn't?
Like Linux distribution, software versions, etc

@lesterlo this is NOT the same issue, and ARM computers aren't supported here or by Mojang

[edgarogh]

I FOUND IT !

I took a bit of time trying to reproduce the bug on the computer where it worked, and I managed to make Minecraft crash too.

See, I'm French. We use funny-looking dressed-up letters such as this magnificent "é". Although the world is supposed to use UTF-8 everywhere and even almost not care about the bytes that make up any string, it just happens that in the huge technological stack required to launch Minecraft (MMC, Java, MMC's bootstrap code, Minecraft, LWJGL...) a little rascal misbehaves when exposed to non-English characters, and produces a very unclear – almost unrelated – error that took hours to debug.

Well I still don't know what causes the bug precisely and more importantly why, but I can definitely tell you that the Minecraft instance can be started if its directory name contains strictly ASCII characters, and crashes when it contains an "é". This has to do with the directory name, not the instance name, which can differ if the instance is renamed after its creation.

It is worth mentioning that:

• The official Minecraft Launcher does manage to launch the instance, even when the "Game directory" is set to the MultiMC instance's .minecraft. That said, I'm pretty sure that the official launcher stores its libraries and similar stuff in one centralized place, so their path remains clear of any non-ASCII chars.
• I tried to Ctrl + F in the crash log from MultiMC to see if the instance directory name had had its "é" stripped somewhere, and no, all paths look fine here. It must be a much harder-to-debug end-of-chain problem 😈

How to fix it quickly myself ?

Erase your language's culture_(/s), rename your instance DIRECTORIES (not the instances themselves from the contextual menu) so they only contain American© Standardized™ letters

How can it be fixed upstream ?

• Find out who's actually responsible for the problem
• Fix it

or

• When creating an instance with alien characters in its name, try to derive a directory name without them. This can be done very naively by removing the offending chars, or more carefully by trying to find a good enough equivalent ("é" becomes "e" for instance)

[kb-1000]

In theory, Unicode handling should work on Linux (not on Windows though)
Something is going wrong there, but without further info it's hard to debug... and that further info would be the exception that's missing from the log.
Getting it wouldn't be very easy though.
I can reproduce the issue on my machine.

[kb-1000]

[22:55:10] [Render thread/INFO]: [STDERR]: java.lang.ExceptionInInitializerError
[22:55:10] [Render thread/INFO]: [STDERR]: 	at dvt.<init>(SourceFile:157)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at dvp.<init>(SourceFile:459)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at net.minecraft.client.main.Main.main(SourceFile:179)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:210)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:245)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at org.multimc.EntryPoint.listen(EntryPoint.java:143)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at org.multimc.EntryPoint.main(EntryPoint.java:34)
[22:55:10] [Render thread/INFO]: [STDERR]: Caused by: java.lang.RuntimeException: java.lang.UnsatisfiedLinkError: Failed to dynamically load library: /home/kb1000/MultiMC5-Install/instances/pré1.18/natives/libglfw.so(error = /home/kb1000/MultiMC5-Install/instances/pré1.18/natives/libglfw.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at dpg.<clinit>(SourceFile:46)
[22:55:10] [Render thread/INFO]: [STDERR]: 	... 11 more
[22:55:10] [Render thread/INFO]: [STDERR]: Caused by: java.lang.UnsatisfiedLinkError: Failed to dynamically load library: /home/kb1000/MultiMC5-Install/instances/pré1.18/natives/libglfw.so(error = /home/kb1000/MultiMC5-Install/instances/pré1.18/natives/libglfw.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at org.lwjgl.system.linux.LinuxLibrary.loadLibrary(LinuxLibrary.java:32)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at org.lwjgl.system.linux.LinuxLibrary.<init>(LinuxLibrary.java:19)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at org.lwjgl.system.APIUtil.apiCreateLibrary(APIUtil.java:123)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at org.lwjgl.system.Library.loadNative(Library.java:335)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at org.lwjgl.system.Library.loadNative(Library.java:281)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at org.lwjgl.system.Library.loadNative(Library.java:205)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at org.lwjgl.glfw.GLFW.<clinit>(GLFW.java:674)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1155)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at java.base/java.lang.invoke.DirectMethodHandle$EnsureInitialized.computeValue(DirectMethodHandle.java:378)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at java.base/java.lang.invoke.DirectMethodHandle$EnsureInitialized.computeValue(DirectMethodHandle.java:375)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at java.base/java.lang.ClassValue.getFromHashMap(ClassValue.java:228)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at java.base/java.lang.ClassValue.getFromBackup(ClassValue.java:210)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at java.base/java.lang.ClassValue.get(ClassValue.java:116)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at java.base/java.lang.invoke.DirectMethodHandle.checkInitialized(DirectMethodHandle.java:401)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at java.base/java.lang.invoke.DirectMethodHandle.ensureInitialized(DirectMethodHandle.java:389)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at java.base/java.lang.invoke.DirectMethodHandle.ensureInitialized(DirectMethodHandle.java:423)
[22:55:10] [Render thread/INFO]: [STDERR]: 	at dpg.<clinit>(SourceFile:43)

This gives away that it's most likely some sort of encoding issue.
After some more looking at it, I found this:

The ASCII method encodes text as ISO-8859-1 (also known as latin1), and the dlerror method also uses the same encoding to decode the error.
It should be UTF-8 though.
On Mojang's launcher, the files are extracted into the bin folder and probably get a relative path to there, which means this isn't an issue there. MultiMC uses an absolute path. I'd say this is a LWJGL bug surfaced by a behavioral difference between Mojang's launcher and MultiMC.

[kb-1000]

Plus an MC bug that silences the original exception, of course.
While running that debugger I also found that it silences the failure to load jemalloc.

[edgarogh]

You're incredibly fast, I was trying to diff the strace output to see if a dynamic library path was wrong. Good job on finding the cause of the issue. Are you going to open an issue on LWJGL's repo or should I do it ? I have plenty of time but you probably understand the bug more than I do.

[kb-1000]

It looks as if LWJGL 3.3.0 or 3.2.3 fixed this issue.
Minecraft still uses 3.2.2.

[kb-1000]

LWJGL/lwjgl3@a10f862
LWJGL/lwjgl3#691
It got fixed in LWJGL 3.3.0. I guess this fix could be backported?
Though, as you can see here: https://github.com/LWJGL/lwjgl3/blob/6da65e3c2aca8654ef6fdb0d0520994b43ea90d2/modules/lwjgl/core/src/generated/java/org/lwjgl/system/linux/DynamicLinkLoader.java#L102
dlerror still uses the wrong encoding. I think that should still be reported.

[Glavo]

Hi, I found and reported this problem at the end of October.
I fixed it with this workaround in HMCL:

https://github.com/huanghongxun/HMCL/pull/1145

When a non ASCII character is detected in the native library path, we create a soft link for it in /tmp and insert the soft link path to the front of the java.library.path.

[Am3ra]

Is there anything end-users like me could do to fix it locally?

[Glavo]

Is there anything end-users like me could do to fix it locally?

Run in a directory where the path contains only ASCII characters.

[Am3ra]

Issue is with arm Mac I think, which lwjgl doesn't support apparently

[edgarogh]

@Am3ra Check this reply: #4205 (comment)

this is NOT the same issue, and ARM computers aren't supported here or by Mojang

[USMP-lancer]

that lib apparently has arm builds now, but mojang has yet to add the libraries themselves, which might work

[1oglop1]

@peterix Since you removed the issue about Mac M1 and arm binaries, can we follow up on the problem in this one or create a new issue?