Kotlin/Native test-binary linker crashes (SIGSEGV) on Linux dev hosts under memory pressure

[jamesarich]

./gradlew build cannot complete on at least one Linux x64 dev host: the Gradle daemon dies with a JVM SIGSEGV during linkDebugTestLinuxX64 (and linkDebugTestLinuxArm64 / linkDebugTestMingwX64), inside the in-process Kotlin/Native compiler's teardown — the crash trace points at kotlinx.cinterop.Caches.disposeFfi → ffiFreeClosure0 → jni_DeleteGlobalRef, with the hs_err log showing the fault inside AccessInternal/G1BarrierSet.

Confirmed pre-existing, not a regression

Reproduced identically on pristine main (commit fba1059) with no source changes at all — three independent sessions on the same host hit the exact same crash while working on unrelated branches. It survived every workaround tried in those sessions:

• Larger daemon heap (-Xmx6g)
• --no-parallel --max-workers=1
• Switching GC / out-of-process compiler flags
• Stopping all Gradle/Kotlin daemons first and retrying cold
• Running outside the sandboxing layer of the coding-agent tool

Likely trigger

The host was under heavy memory pressure at the time (multiple concurrent Gradle daemons / agent processes, tens of GB resident, some swap activity). This may be specific to constrained/contended memory rather than a pure toolchain bug — worth checking whether it reproduces on a quiet host before assuming it's universal. JDK is Nix-provided 21.0.12.

What still verifies cleanly

The crash happens after the linker has already written the test binary, so the native leg isn't actually unverified:

• ./gradlew build -x linkDebugTestLinuxX64 -x linuxX64Test -x linkDebugTestLinuxArm64 -x linkDebugTestMingwX64 → BUILD SUCCESSFUL (covers compilation of every target's klib, apiCheck, spotlessCheck, detekt, and every runnable test target: JVM, JS, Wasm).
• The already-linked build/bin/linuxX64/debugTest/test.kexe runs standalone and passes in full when invoked directly, bypassing Gradle's link step.

So this blocks a fully green ./gradlew build locally on an affected host, but doesn't appear to indicate a real test failure — CI (which this project runs cross-platform) should be checked for the same signature before concluding it's host-specific.

Repro

./gradlew linkDebugTestLinuxX64
# or: ./gradlew build

on a Linux x64 host with significant concurrent memory pressure.

[jamesarich]

Root cause found, and it's reproducible/deterministic, not intermittent.

It's the Nix-packaged JDK build specifically. The crash log's RBX/R12 frames point at /nix/store/.../openjdk-21.0.12+2/..., and the JVM banner confirms 21.0.12+2-nixos. Re-running the exact same task (linkDebugTestLinuxX64) with JAVA_HOME pointed at the distro's own OpenJDK build (Ubuntu 26.04's 21.0.11+10-1-26.04.2-Ubuntu, /usr/lib/jvm/java-21-openjdk-amd64) instead — BUILD SUCCESSFUL, all 71 native tests pass, confirmed with --rerun-tasks to rule out caching.

Also ruled out: daemon reuse (--no-daemon still crashes under the Nix JDK — same task, same frame, deterministic every time), so this isn't the "loaded twice across a long-lived daemon" class of Kotlin/Native bug. It's specific to something in the Nix build of OpenJDK 21.0.12+2 interacting badly with Kotlin/Native's libffi-based JNI bridge (libkotlinxcinteropjvmcallbacks.so) during the in-process K2Native compiler's FFI-closure teardown (kotlinx.cinterop.Caches.disposeFfi → ffiFreeClosure0 → jni_DeleteGlobalRef, faulting inside G1's oop_access_barrier).

Workaround usable today, no repo changes needed:

JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64 ./gradlew linkDebugTestLinuxX64

(or any Kotlin/Native link/test task on this host.)

Structural fix would mean changing the pinned JDK in the workspace's shared .#kotlin Nix devshell (used by kzstd, TAKPacket-SDK, MQTTastic-Client-KMP, gradle-flatpak-sources, and meshtastic-sdk) — bigger blast radius, needs its own investigation into why that specific nixpkgs JDK derivation was pinned before swapping it. Tracking that separately at the workspace level rather than here.