AppImage segfaults on every launch because of buffer overflow

System: Arch Linux, KDE 6.7, Kernel 7.0

Both the 1.7.1 and 1.7.2 Linux AppImage builds crash with SIGSEGV on every launch, before the JVM/UI ever starts. The crash is inside glibc's setenv(), called from the bundled native launcher. Extracting AppImage and executing dev.dimension.flare.MainKt directly works fine.

journalctl -k shows the fault always at the same libc offset, in the first instruction of setenv()'s internal strlen, dereferencing a bogus pointer.

Running with JPACKAGE_DEBUG=true ./Flare-1.7.2.appimage prints this:

[TRACE] JvmLauncher.cpp:313: Need 30649 bytes for JvmlLauncherData buffer
[TRACE] JvmLauncher.cpp:310: Initialized 30649 bytes at 0x... address
...
[pid]: jli arg[2]: [-classpath value, truncated mid jar filename ...core-jvm-1.0.1-1ec2c256]
[pid]: jli arg[3]: []
[pid]: jli arg[4]: []
... (args 3–13 all empty)

I suspect that -classpath grows too large, not fitting into the allocated memory, and leads to this crash.

Workaround that I used to launch the app:

./Flare-*.appimage --appimage-extract
cd squashfs-root
./lib/runtime/bin/java -cp 'lib/app/*' \
    -Dcompose.application.resources.dir="$PWD/lib/app/resources" \
    -Dskiko.library.path="$PWD/lib/app" \
    -Dnucleus.executable.type=appimage -Dnucleus.app.id=Flare \
    --enable-native-access=ALL-UNNAMED dev.dimension.flare.MainKt

Start with the bundled native launcher around JvmLauncher.cpp lines 310 and 313, using JPACKAGE_DEBUG=true on the AppImage to inspect the allocated JvmlLauncherData buffer and generated arguments. Compare the launcher output with the extracted runtime invocation, especially the oversized classpath and empty arguments. Done means both 1.7.1/1.7.2-style AppImages launch without SIGSEGV and pass the expected classpath and arguments.