Fix crashes and corruption with many custom music tracks (audio heap overflow) - #6932
Open
lunks wants to merge 1 commit into
Open
Fix crashes and corruption with many custom music tracks (audio heap overflow)#6932lunks wants to merge 1 commit into
lunks wants to merge 1 commit into
Conversation
Member
|
Author
|
serprex
self-requested a review
July 15, 2026 17:17
…music packs)
Root cause of three identical field crashes (audio thread, opcode fetch
through a pointer with its low 32 bits overwritten, seconds after scene
transitions): AudioHeap_AllocPermanent writes permanentCache[index] with
index = permanentPool.count and no bound against the 32-entry array. In
SoH every soundfont sync-load is forced permanent, and custom sequences
whose SEQ.xml says CachePolicy="Temporary" ALSO allocate permanently
(the factory stores the LUS enum where CACHE_TEMPORARY == 0, while
AudioLoad_SyncLoad's switch reads 0 with the ROM convention
'permanent'). A pack with ~60 streamed customs plus vanilla fonts pushes
count past 32 within a session, after which each allocation sprays a
{ptr, size, tableType/id} triplet at 24-byte stride through
gAudioContext - entry[135]'s ptr field lands exactly on
seqPlayers[0].scriptState.pc and entry[156] on seqPlayers[1]'s (both
verified against the crash-dump registers).
- permanentCache raised 32 -> 512 (12 KB) and AllocPermanent refuses
allocations past the array instead of corrupting memory.
- Same unbounded-index disease fixed in the three sibling writers:
AllocCached's persistent path (16-entry array; CACHE_EITHER degrades
to temporary, hard persistent requests fail cleanly),
AllocPersistentSampleCacheEntry, AllocTemporarySampleCacheEntry.
- seqLoadStatus malloc sized for the full id space (sequenceMapSize +
0xF) matching sequenceMap; custom ids above sequenceMapSize previously
overflowed the allocation by up to 15 bytes.
Upstream SoH bugs, not branch-introduced - this branch's many-track
packs merely made the overflow reachable in normal play. Standalone
upstreamable fix.
Claude-Session: https://claude.ai/code/session_01Sxa5kfXEtLwWmZ1Ht692oa
lunks
force-pushed
the
fix/6900-audio-heap-cache-overflow
branch
from
July 15, 2026 17:18
61bda67 to
36c0103
Compare
|
Crashes are completely fixed, that's what my case testing ended up on at least. Tested with my earlier ~60 song setup (see #6900) and another where i literally just dumped every SAF mod i have, like 2GB of unorganized junk. it seemed to be at least ~600-700 tracks, so most tracks were corrupted, or displayed the wrong name (shocker i know) — but no crashes !! Both #6916 and #6932 combined seemed to fix the most frustrating symptoms at least. I might do another test with ~300-400 tracks to confirm the 512 limit. Regular gameplay even with a bulky music pack will not be affected by crashes anymore. Probably. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes a crash with large custom music packs
Companion to #6916 — that PR fixed one out-of-bounds write (
AudioLoad_SetFontLoadStatus); this one fixes a separate overflow it doesn't touch.The audio engine keeps a fixed 32-entry list of permanently-loaded audio (
permanentCache) and never checks the limit when adding to it. With a large custom pack, every track loads permanently (both its soundfont and its sequence), so the list fills past 32 within a session and each further entry gets written past the end — over neighbouring audio state, eventually the sequence players' script pointers, which crashes the audio thread (#6900, still reproducible after #6916).Fix
Vanilla sessions stay well under the limit, so stock behaviour is unchanged. Technical detail is in the commit message.
Build Artifacts