[Bug] SDK 22.2.0 titles abort during `sdk` module init: TlsHeapCentral::LockMutexSlow_

[Appealpotato]

Prerequisites

• I am confident that my issue has not been reported already in open OR closed issues.
• I am able to reliably reproduce the issue on the latest stable or canary version.
• I am not using an unofficial build (Flatpak, Emudeck, etc.).
• I am a silly goose and didn't read these boxes.
• I am a silly goose and DID read these boxes.

Description of the issue

Environment

• Ryujinx Canary 1.3.351 (2026-08-26) — latest as of 2026-09-01
• OS: Windows x64
• Firmware installed in Ryujinx: 22.1.0
• Game: Can I Not Fall for Idols? (アイドルと〇〇しちゃダメですか) — [0100C6B028F38000][v0][BASE] (eShop, released 2026-08-27)
• Loader reports: FS SDK Version: 22.2.0, SDK libraries include NintendoSdk_nnSdk-22_2_0-Release

Symptom

With the ZBIC workaround applied (see the companion ZBIC issue — main rebuilt uncompressed, ExeFS replaced via mod), the game loads all modules, maps images, initializes the GPU and starts applet services, then the guest aborts at ~4.6s:

|E| KernelSvc Break: The guest program broke execution!
|E| Application : Unhandled exception caught: Ryujinx.HLE.Exceptions.GuestBrokeExecutionException
   at Ryujinx.HLE.HOS.Kernel.SupervisorCall.Syscall.Break(UInt64 reason)

Guest stack trace (main thread)

nn::diag::detail::VAbortImpl
nn::diag::detail::AbortImpl(nn::Result const*)
nn::nlibsdk::heap::TlsHeapCentral::LockMutexSlow_()
nn::nlibsdk::heap::CentralHeap::MakeCache(nn::nlibsdk::heap::CachedHeap*)
nn::mem::StandardAllocator::Allocate(unsigned long, unsigned long)
__nnmusl_init_dso
_init
nn::init::Start(unsigned long, unsigned long, void (*)(), void (*)(), void (*)())

called from rtld entry — i.e. the crash happens during the new SDK 22.2.0 dedicated sdk module's init (musl-based C runtime + new per-thread heap cache allocator), before main's entry runs.

Notable (possibly garbage) register values at abort: X10 = 0xffffff80ffffffe8, X12 = 0x5c79000000000000.

Analysis

The new allocator stores per-thread heap state in TLS (TlsHeapCentral = central heap + per-thread CachedHeaps) and locks a central mutex when creating a thread's first cache. The lock fails with an nn::Result → nn::diag aborts the process.

This points to an emulation gap in the HOS process setup for the new SDK layout, e.g.:

• TLS area size/layout (the sdk module contains musl, which has its own TLS requirements; the loader must size the TLS block from the modules' dynamic TLS info), and/or
• process heap region setup (heap size / memory pool from the new npdm or loader path), and/or
• address-arbiter / mutex syscall semantics used by the new mutex slow path.

Confirms it's an emulator issue, not a bad dump

The same game + same ZBIC-stripped ExeFS boots and plays on real hardware (Switch emuMMC, Atmosphere 1.11.2). Stock hardware provides the TLS/heap/mutex setup the new SDK expects, so this is purely a Ryujinx HLE gap for SDK 22.x processes.

Reproduction steps

• Launch game normally through the emulator.
• It crashes shortly after loading (after the emulator loading screen).

---

Repro

1. Any SDK 22.2.0 title with the dedicated sdk NSO in ExeFS (this game, or any future 22.x release).
2. Apply the ZBIC workaround (uncompressed main via mod exefs.nsp) so loading succeeds.
3. Launch — observe the guest abort in TlsHeapCentral::LockMutexSlow_.

Log file

Ryujinx_Canary_1.3.351_2026-09-01_14-04-46.log

OS

Windows 10 x64

Ryujinx version

1.3.351

Game version

No response

CPU

Ryzen 5600x

GPU

RTX 3060Ti

RAM

32GB

List of applied mods

exefs.nsp - ExeFS replacement: main NSO decompressed from ZBIC → rebuilt uncompressed (flags 0x38, segment hashes verified against header). Only mod applied. Stock main fails to load (see ZBIC issue), so this is required to reach the crash.

Additional context?

No response

[GreemDev]

Did you use AI to help write this issue?

[Appealpotato]

Answered over in #492, log's over there too. (ゝω･)v