Switch crashes (reboot required) when exiting SDL2 audio homebrew launched from Sphaira in title override mode

[Dcnigma]

Summary

When launching a homebrew that uses SDL_INIT_AUDIO from Sphaira in title override mode and then exiting, the entire Nintendo Switch crashes and requires a hard reboot. The same scenario with nx-hbmenu only produces a soft "software closed due to error" message — the Switch keeps running. This is a known class of issue affecting Retroarch, Moonlight, and other SDL2 audio homebrews but appears to be worse (full reboot vs soft error) when using Sphaira specifically.

Environment

• Atmosphère version: 1.9.5-master-de9b02007
• Sphaira version: 1.0.0
• Firmware version: 20.1.0
• Launch method: Title override mode (NOT applet mode)
• Homebrew: Winamp Custom SDL2 music player using SDL_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO)
  Unreleased: ( https://github.com/Dcnigma/WINAMP-switch-Clone )

Behavior Comparison

Launcher	Mode	On Exit
Sphaira	Title override	💥 Full Switch crash, reboot required
nx-hbmenu	Title override	⚠️ "Software closed due to error" — Switch stays running
Forwarder / direct HOS	Title (standalone)	✅ Clean exit, no error

The difference in severity between Sphaira (full crash) and nx-hbmenu (soft error) suggests Sphaira's post-exit cleanup is more aggressive in a way that causes a fatal cascade into the bsdsocket system module.

How to Reproduce

1. Launch Sphaira in title override mode (hold R while opening a game)
2. Launch any NRO that calls SDL_Init(SDL_INIT_AUDIO)
3. Exit the homebrew (e.g. press Plus)
4. Switch crashes and requires a reboot

Crash Reports

Two Atmosphère crash reports are generated.

Crash 1 — Sphaira itself

Result:        0x4A8 (2168-0002)
Process:       Application (sphaira)
Program ID:    05446530aca7e000
Exception:     Data Abort
Fault Address: 0x0000000000000000  ← null pointer dereference

PC:  sphaira + 0x219a94
LR:  sphaira + 0x6bf00

Stack Trace — every address is inside sphaira, homebrew code not present:
  [0] sphaira + 0x6ce0c   ← identical in all test runs
  [1] sphaira + 0x7f840   ← identical in all test runs
  [2] sphaira + 0x1b340
  [3] sphaira + 0x48d4c
  [4] sphaira + 0x18188
  [5] sphaira + 0x51f44
  [6] sphaira + 0xad0
  [7] sphaira + 0xa40

Crash 2 — bsdsocket system module (causes the reboot)

Result:        0x4A8 (2168-0002)
Process:       bsdsocket (0100000000000012)
Exception:     Data Abort
Address:       0x0000000000000040  ← vtable read at +0x40 from null
Fault Address: 0x0000000000000000

PC:  [bf02b2ce] + 0x5c450

Stack Trace — byte-for-byte identical across all 3 test sessions:
  [0] + 0x68c48
  [1] + 0x5f22c
  [2] + 0x6a3f8
  [3] + 0x6a388
  [4] + 0x6cde8
  [5] + 0xd9308
  [6] + 0xdb158
  [7] + 0xdaf0c
  [8] + 0xd9e64

X[22] = 0x8e  ← the homebrew's Process ID, confirmed from Crash 1

Because bsdsocket is a system module, its crash cannot be recovered from — hence the reboot.

Root Cause Analysis

What happens

1. Homebrew exits cleanly (all threads stopped, SDL shut down, romfsExit() called, return 0)
2. Sphaira's post-exit cleanup tries to reclaim the memory region that belonged to the homebrew process
3. Sphaira dereferences a null pointer in its own cleanup code → Crash 1
4. bsdsocket still holds a reference to the homebrew by Process ID 0x8e (registered when SDL_INIT_AUDIO opened its audio socket)
5. bsdsocket tries to close sockets for the now-dead process, reads a vtable pointer at +0x40 from an already-freed socket struct → null deref → Crash 2
6. System module crash = Switch must reboot

Why this is a Sphaira bug, not a homebrew bug

• The entire Crash 1 stack trace is inside Sphaira — the homebrew's code does not appear anywhere
• The bsdsocket stack trace is 100% reproducible and identical regardless of what cleanup code the homebrew runs
• We tested all of the following in the homebrew — none had any effect on the crash:
  • appletSetFocusHandlingMode(AppletFocusHandlingMode_NoSuspend)
  • appletGetMessage() exit detection loop
  • SDL_QuitSubSystem(SDL_INIT_VIDEO | SDL_INIT_AUDIO) instead of SDL_Quit()
  • Explicit playerShutdown() before SDL cleanup
  • Full thread join before any SDL teardown

Why nx-hbmenu only gives a soft error

nx-hbmenu uses a different (less aggressive) process lifecycle. It doesn't trigger the Sphaira-specific null deref, so the crash stops at a soft error rather than cascading into bsdsocket.

This is a known class of issue

GBAtemp thread "Software closed because an error occurred" when exiting certain apps like Retroarch or Moonlight from Hbmenu or Sphaira in title override mode (Feb 2026) describes the same "software closed" error from both Hbmenu and Sphaira. Retroarch and Moonlight are both SDL2 audio apps. The difference is that Sphaira causes a full reboot while Hbmenu only gives the soft error.

Your own release 0.6.1 notes mention:

"fixed applet mode crash if launched with a game that uses multiple audren services"

This confirms prior sensitivity to audio homebrew in Sphaira. This bug may be the same root cause resurfacing in the title override exit path.

Suggested Fix Area

The two stack offsets consistent across every single crash across all test sessions point to the most likely bug location in Sphaira:

sphaira + 0x6ce0c   ← ReturnAddress[0], every crash
sphaira + 0x7f840   ← ReturnAddress[1], every crash

The null dereference is in Sphaira's homebrew exit/cleanup path, likely in the sequence that reclaims the homebrew's address space. A fix might involve:

• Waiting for bsdsocket (and other system modules holding process references) to release their handles before reclaiming the homebrew's address space
• Using the appropriate kernel/IPC call to signal the process as fully terminated before memory reclamation
• Comparing with nx-hbmenu's post-exit cleanup sequence to find what Sphaira does differently

Workaround

Running the homebrew as a standalone title via a forwarder completely avoids the issue. Not practical for most end users.

---

2 Atmosphère .log crash files are attached.

[Dcnigma]

01778311430_05446530aca7e000.log
01778311430_0100000000000012.log

[NaGaa95]

The root cause appears different from the proposed cleanup/bsdsocket explanation

The crash occurs inside stb_image while reloading the homebrew icon, not while unloading the previous NRO.
Your Winamp embeds a 3840×3863 PNG as its NRO icon, requiring roughly 56.6 MiB when decoded.
Sphaira currently decodes it without checking its dimensions and then creates a full-size GPU texture.

This also explains the different results :
nx-hbmenu expects a JPEG icon and rejects this PNG.
The forwarder converts it to a normal 256×256 JPEG.
Sphaira attempts to decode the original oversized PNG and crashes.

This is still a valid Sphaira robustness issue and i'll add proper icon validation, checked image-size calculations, downscaling, and a default-icon fallback for oversized or invalid images.

You should rebuild Winamp using a proper 256×256 JPEG icon and retest