[nafields]

What and why

Symptom: The Legend of Zelda: Ocarina of Time (Switch 2, 0400486024DEC000, update v131072, SDK 22.2.8) crashed on the audio render thread minutes into its opening movie:

• CRASH sig=11 addr=0x20 at nn::audio::server::AddressInfo::GetReference (sdk+0x249874);
• the stack was under CommandGenerator::GenerateDataSourceCommand and render_once;
• the AddressInfo it read was all zeros, though the function had just read a non-null memory pool pointer from it.

Cause: the Span layout (SDK 19 and later) took AudioRenderSystem's update lock at a fixed +0x2d0.

• SDK 22.2.8's UpdateImpl (sdk+0x238530) locks the SdkMutexType at +0x2d8: add x19, x0, #0x2d8; …; mov x0, x19; bl SdkMutexType::Lock.
• Locked at +0x2d0, the render thread excluded nothing and wrote a lock word into the field before the mutex. The game's RequestUpdate then rewrote a voice while its commands were being generated.
• update_lock already reads the offset off the SDK's own code for the older layouts, but it reads Update. From SDK 20, Update reads the system tick and calls UpdateImpl, which takes the lock.

Fix: update_lock now takes the function to read, and the Span layout reads UpdateImpl (hle_audren.c).

• It keeps +0x2d0 when it finds no SdkMutexType::Lock there.
• The start-up line names the offset it took: update lock SdkMutexType at +0x2d8.

Reference entry: The update lock read off UpdateImpl (SDK 22). It is linked from SDK 20's layout entry, and the symptom index is regenerated.

Checked

• Tests:
  • make -C dm/host/tests GAME=0400C3F00006E000 run passes.
  • python3 -m unittest dm/tools/tests/test_docs.py passes.
  • The host builds.
• Games run: The Legend of Zelda: Ocarina of Time (0400486024DEC000, v131072), on [WIP] The Legend of Zelda: Ocarina of Time (Switch 2, 0400486024DEC000, v0, SDK 22.2.8) runs on the Mac through the title movie into Kokiri Forest #1299's profile (this PR adds no profile).
  • Before the change, the second run through the opening crashed as above.
  • With it, the opening played through to Kokiri Forest, which ran with sound.
• Static check: the prologue read the way update_lock reads it gives +0x2d0 for Mario Kart World's sdk (0400C3F00006E000, SDK 19.3.3), as before, and +0x2d8 for Ocarina's.
• Devices and OS: M3 16 GB, macOS 26.6.2.
• regress.py: not run. The change reaches only Span-layout games (SDK 19+), whose offset it now reads instead of assuming. On those whose UpdateImpl locks +0x2d0, as Mario Kart World's does, the value is the same as before.
• Not checked:
  • lint_c.py tidy (no LLVM on this Mac);
  • Mario Kart World and other SDK 19–21 games at run time.

Docs

• The finding is in its docs/reference/audio.md entry, and python3 dm/tools/docs_symptoms.py was run
• No game files, keys or data extracted from a game in the change or the attachments

[seedds]

Landed as 5219060, with your diagnosis and your fix for the offset, and you are credited as co-author. Thank you: the bug was real, and SDK 22.2.8's UpdateImpl, SendCommandToDsp, Start, Stop and FinalizeImpl all use +0x2d8.

What changed from this pull request:

• update_lock reads Update, then UpdateImpl, for every SDK, so there is no gen20 branch in the lookup.
• A miss in both now logs a [RED] line instead of quietly keeping the fixed offset.
• t_audren_layout tests the scan.
• The docs say the lock moved to UpdateImpl from SDK 19, not 20, and add 18.3's +0x208.

Checked statically on the sdk builds on hand: SDK 19.3 to 21.4 still read +0x2d0, and 22.2.5 and 22.2.8 read +0x2d8. No game has run this exact form yet, because Ocarina's profile is still in #1299. Your run used the form in this pull request. If you run it on top of #1299, the start-up line should say update lock SdkMutexType at +0x2d8.

#1444 carries the old form of these lines and will need a rebase.

[Romen-Adama-Dev]

Confirmed on an Apple M3 Pro (18 GB), macOS 27.0.1, update v131072, with #1299 merged onto main 865cc35f: the start-up line reads update lock SdkMutexType at +0x2d8, the opening and about 20 minutes in Kokiri Forest played with sound, and the audio render thread did not crash (it had not crashed for me without this change either, over about an hour of runs, so this is a no-regression report rather than a reproduction of the crash).