1.19 fails to launch with crashing Java

[PureTryOut]

Operating System

Linux

Version of PolyMC

1.3.1

Description of bug

When launching a clean Minecraft1.19 instance (freshly made) with either Java 1.17 or Java 1.18, Java crashes and the game never launches. The same Java versions however can be used to launchMinecraft 1.18 and lower just fine.

[11:37:45] [main/INFO]: Building optimized datafixer
[11:37:47] [Render thread/INFO]: Environment: authHost='https://authserver.mojang.com', accountsHost='https://api.mojang.com', sessionHost='https://sessionserver.mojang.com', servicesHost='https://api.minecraftservices.com', name='PROD'
[11:37:48] [Render thread/INFO]: Setting user: PureTryOut
[11:37:48] [Render thread/INFO]: Backend library: LWJGL version 3.3.1 build 7
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00000000000239a6, pid=16237, tid=16238
#
# JRE version: OpenJDK Runtime Environment (18.0.1+10) (build 18.0.1+10-alpine-r1)
# Java VM: OpenJDK 64-Bit Server VM (18.0.1+10-alpine-r1, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  0x00000000000239a6
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/bart/Nextcloud/CloudSave/Minecraft/instances/Newest/.minecraft/hs_err_pid16237.log
#
# If you would like to submit a bug report, please visit:
#   https://gitlab.alpinelinux.org/alpine/aports/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Process crashed with exitcode 6.

However I can run Minecraft 1.19 using the official Mojang launcher (in a Flatpak) perfectly fine.

Steps to reproduce

• Create a new, clean, instance for 1.19
• Launch it

Suspected cause

No response

This issue is unique

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

[DioEgizio]

Please send logs:

[Scrumplex]

While you are at it, feel free to send the hs_err_pid16237.log it mentions there as well. I suspect that there is some incompatibility with some library.

[DioEgizio]

I also suspect it's something with alpine and you should try the PolyMC flatpak

[PureTryOut]

hs_err_pid16237.log

https://mclo.gs/xt1aI3M

[DioEgizio]

odd, try redoing the instance but i suspect it's something with alpine

[PureTryOut]

The Flatpak launches fine indeed. Note that I was earlier just changing an existing 1.18 instance to 1.19 in which this occurred, after which I made a fresh one for 1.19 instead.

"Something with Alpine" is a bit vague, it's just the good ol' openjdk, do you know a bit more?

[Scrumplex]

Can you see if it works using the official launcher (outside of Flatpak)?
Looking at the hs_err_pid log it is a segfault with LWJGL. 1.19 updated to LWJGL 3.3.1, so there might even be a bug in LWJGL itself.

[PureTryOut]

I can not. Alpine Linux uses Musl libc and the official launcher uses Electron which requires glibc... Just one of several reasons I prefer PolyMC 😅

[Scrumplex]

I personally didn't use Alpine Linux much outside of containers or very light workloads for Raspberry Pis, so maybe this is complete bullshit. But maybe you are able to use gcompat as explained on the Alpine wiki: https://wiki.alpinelinux.org/wiki/Running_glibc_programs

[ptrcnull]

i've stumbled over the same issue, from my experience it's not limited to 1.19 either; mojang distributes liblwjgl.so pre-compiled against glibc which doesn't work under musl, either with gcompat or without.

$ ldd /tmp/lwjglpatrycja/3.3.1-build-7/liblwjgl.so
	/lib/ld-musl-x86_64.so.1 (0x7f2e3e6b9000)
	libpthread.so.0 => /lib/ld-musl-x86_64.so.1 (0x7f2e3e6b9000)
	libc.so.6 => /lib/ld-musl-x86_64.so.1 (0x7f2e3e6b9000)
	libdl.so.2 => /lib/ld-musl-x86_64.so.1 (0x7f2e3e6b9000)
Error relocating /tmp/lwjglpatrycja/3.3.1-build-7/liblwjgl.so: __snprintf_chk: symbol not found
Error relocating /tmp/lwjglpatrycja/3.3.1-build-7/liblwjgl.so: pwritev64v2: symbol not found
Error relocating /tmp/lwjglpatrycja/3.3.1-build-7/liblwjgl.so: preadv64v2: symbol not found

GDB stacktrace

(gdb) bt full
#0  a_crash () at ./arch/x86_64/atomic_arch.h:108
No locals.
#1  abort () at src/exit/abort.c:27
No locals.
#2  0x00007fa25f524951 in ?? () from /usr/lib/jvm/java-18-openjdk/lib/server/libjvm.so
No symbol table info available.
#3  0x00007fa2601bab70 in ?? () from /usr/lib/jvm/java-18-openjdk/lib/server/libjvm.so
No symbol table info available.
#4  0x00007fa2601bb546 in ?? () from /usr/lib/jvm/java-18-openjdk/lib/server/libjvm.so
No symbol table info available.
#5  0x00007fa2601bb56a in ?? () from /usr/lib/jvm/java-18-openjdk/lib/server/libjvm.so
No symbol table info available.
#6  0x00007fa260063b72 in JVM_handle_linux_signal () from /usr/lib/jvm/java-18-openjdk/lib/server/libjvm.so
No symbol table info available.
#7  <signal handler called>
No locals.
#8  0x00000000000239a6 in ?? ()
No symbol table info available.
#9  0x00007fa22e5f181d in ?? () from /tmp/lwjglpatrycja/3.3.1-build-7/liblwjgl.so
No symbol table info available.
#10 0x00007fa22e5f1ad5 in ?? () from /tmp/lwjglpatrycja/3.3.1-build-7/liblwjgl.so
No symbol table info available.
#11 0x00007fa22e5eda45 in ?? () from /tmp/lwjglpatrycja/3.3.1-build-7/liblwjgl.so
No symbol table info available.
#12 0x00007fa22e5ee73d in ?? () from /tmp/lwjglpatrycja/3.3.1-build-7/liblwjgl.so
No symbol table info available.
#13 0x00007fa24802b53a in ?? ()
No symbol table info available.
#14 0x0000000000000000 in ?? ()
No symbol table info available.

one fix would be to add some kind of "use system installation of lwjgl" checkbox, so musl-based distributions could add it as a dependency of polymc; i'm not really sure if that would work though, in case mojang requires different versions of lwjgl for different versions of minecraft

edit: i have noticed that from the 3 symbols reported as glibc-specific only one was actually implemented in gcompat, but even after adding them and explicitly preloading libgcompat it still segfaults in the same way

[PureTryOut]

Oof, ouch, good find! That is a painful change... I never understood why companies shipping proprietary software on Linux don't statically compile it against Musl as that actually works everywhere.

If distributions can manage to ship several versions of lwjgl next to each other, then they could make the PolyMC packaging depend on all the versions Minecraft might require. This would have to be figured out first though, as just shipping one version and hoping that'll work forever won't do. If it is possible though, then a "use system installation of lwjgl" option in PolyMC would indeed help.

[yuri-potatoq]

I had the same issues using nix-flake. Why should this happen with an reproducible environment?
I didnt use the overlays, would be that a problem?
https://mclo.gs/OSN0N6K

[DioEgizio]

if you literally read the comments you would know it only happens on 1.19+

[Username404-59]

if you literally read the comments you would know it only happens on 1.19+

Sorry I didn't take the time to read them all

[Username404-59]

And I can confirm it is not limited to 1.19 as 1.18.2 crashes too

[DioEgizio]

is lwjgl 3 in the version tab set to 3.2.2?

[Username404-59]

Yes it is

[PureTryOut]

Just because it crashes on 1.18.2, it doesn't mean it's the same problem. The issue I reported is specific to 1.19 and higher, and the LWJGL issue as mentioned before is the most likely cause. Please open a separate issue if 1.18 and/or lower versions crash for you.

[Username404-59]

I will proceed but please do not go insulting me if my issue ends up being a duplicate

[ptrcnull]

The issue I reported is specific to 1.19 and higher

i can reproduce it on 1.18, with lwjgl being linked against glibc being the cause of jvm segfaults

if you literally read the comments you would know it only happens on 1.19+

@DioEgizio "if you literally read the comments", just a few comments before yours i said "from my experience it's not limited to 1.19 either".

here's a log from polymc:

Params:
  --username  --version 1.18.2 --gameDir /home/patrycja/.local/share/PolyMC/instances/1.18.2/.minecraft --assetsDir /home/patrycja/.local/share/PolyMC/assets --assetIndex 1.18 --uuid  --accessToken  --userType  --versionType release

Window size: 854 x 480

Java Arguments:
[-Xms4096m, -Xmx4096m, -Duser.language=en]


Minecraft process ID: 7396


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000005736, pid=7396, tid=7397
#
# JRE version: OpenJDK Runtime Environment (18.0.1+10) (build 18.0.1+10-alpine-r1)
# Java VM: OpenJDK 64-Bit Server VM (18.0.1+10-alpine-r1, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  0x0000000000005736
#
# Core dump will be written. Default location: /tmp/core-%t-7396-%e
#
# An error report file with more information is saved as:
# /home/patrycja/.local/share/PolyMC/instances/1.18.2/.minecraft/hs_err_pid7396.log
#
# If you would like to submit a bug report, please visit:
#   https://gitlab.alpinelinux.org/alpine/aports/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Process crashed with exitcode 6.

the lwjgl shared libraries 3.2.1, 3.2.2 and 3.3.1 are all linked to glibc, 3.1.6 or 3.1.2 fail with mismatching function signatures:

Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.NoSuchMethodError: 'org.lwjgl.system.MemoryUtil$MemoryAllocator org.lwjgl.system.MemoryUtil.getAllocator(boolean)' [in thread "Render thread"]
	at dsk.<clinit>(SourceFile:8)
	at dth.<init>(SourceFile:56)
	at dto.<init>(SourceFile:19)
	at dto.<init>(SourceFile:23)
	at dto.<clinit>(SourceFile:11)
	at com.mojang.blaze3d.systems.RenderSystem.<clinit>(SourceFile:46)
	at net.minecraft.client.main.Main.main(SourceFile:194)
	... 7 more

but trying to load 3.1.6 with minecraft 1.13 also segfaults...

as @Username404-59 said in their (now deleted) comment, this indeed happens on 1.13+, and for the exact same reason.

[Scrumplex]

I was trying to reproduce this issue in a VM and was not able to reproduce the issue using 1.18.2 and LWJGL 3.2.2: #1055 (comment)

[ptrcnull]

after more thorough debugging, it turns out the issue is caused by lwjgl 3.3.1 not falling back to the java implementation, but instead trying to load the native libraries regardless. this can be replicated on the older versions by... having the gcompat package installed (as i did) which causes all the native libraries to load, then segfault the render thread.

[Username404-59]

Should #1055 be considered a duplicate since the root issue is (mostly) the same?

[absunth]

if you literally read the comments you would know it only happens on 1.19+

this doesn't seem to be too version specific.
LWJGL 2.XX and LWJGL 3.31 versions don't work, if you're playing on 1.19.2 or other semi-new versions you can revert to LWJGL 3.2.2.

[theofficialgman]

edit: i have noticed that from the 3 symbols reported as glibc-specific only one was actually implemented in gcompat, but even after adding them and explicitly preloading libgcompat it still segfaults in the same way

@ptrcnull if it is segfaulting in the same way, then it seems like did not actually build and install that PR. the symbols should be found then

[ptrcnull]

@theofficialgman it's segfaulting, if the symbols were missing, the executable would not be even launched

[theofficialgman]

@theofficialgman it's segfaulting, if the symbols were missing, the executable would not be even launched

I get that. So ldd is all good now then? Just show the log. It shouldn't have missing symbols anymore if you use that PR

[theofficialgman]

after more thorough debugging, it turns out the issue is caused by lwjgl 3.3.1 not falling back to the java implementation, but instead trying to load the native libraries regardless.

No, that's not what is happening. The native implementation IS the only implementation (always has been, always will be). Lwjgl is a library which functions as a bridge between native code (opengl, vulkan, jemalloc, etc) and java. You simply cannot implement these in the jvm alone

[ptrcnull]

It shouldn't have missing symbols anymore if you use that PR

@theofficialgman and it doesn't.

just to be clear, by "it still segfaults in the same way" i meant the segfault from the original comment on this issue; as i said, missing symbols wouldn't allow the executable to be loaded, so a segmentation fault (which is a runtime error) is not possible in that case.

No, that's not what is happening.

(the following refers to lwjgl <3.3, in my case 3.2.1)
you're right, i double-checked it and it looks like it's only jemalloc - it's not being loaded, because it links against glibc:

# ldd lwjgl-jemalloc-3.2.1-natives-linux/libjemalloc.so
	/lib/ld-musl-x86_64.so.1 (0x7fe0fa208000)
	libpthread.so.0 => /lib/ld-musl-x86_64.so.1 (0x7fe0fa208000)
	libdl.so.2 => /lib/ld-musl-x86_64.so.1 (0x7fe0fa208000)
	libc.so.6 => /lib/ld-musl-x86_64.so.1 (0x7fe0fa208000)
	ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x7fe0f9d99000)

apparently lwjgl can function without jemalloc, as the game launches just fine. the issue occurs when gcompat is present in the system, which causes the shared library to load correctly, but segfault immediately after loading.

[Swivelgames]

Running on Arch Linux, we ran into this issue when trying to run Minecraft 1.19.4

🎉 The solution was to change the LWJGL 3 version to 3.3.1. After that, Minecraft opened up just fine! 🎉

It's important to note that the default version of LWJGL 3 for Minecraft 1.19.4 seems to be 3.1.2, at least in our installation. This is a really old version released back in 2017. However, 3.3.1 was released last year, and seems to solve the problem.

Additionally, we're running Java 17, because it was complaining about Java 20.

Happy Crafting!