Fix stale sound entry access#7488
Merged
Merged
Conversation
JohnAFernandez
approved these changes
May 30, 2026
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
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.
This bug could cause incorrect access to a wrong sound when a soundfile (including none.wav!) was used both in interface sounds and in gameplay sounds. There's more ways than just this sharing to induce the bug, but this is the most surefire way as playing a mission is guaranteed to unload both sets once, thus corrupting sound handles in both arrays. This can CTD, if the game tries to access a sound that was fully removed from the vector of loaded sounds (which happens if the last sound loaded gets unloaded), rather than just invalidated.
To work around the issue, there's two strategies:
Load counters, and not actually unloading a sound until all users no longer need to keep it. This is hard, as the current system isn't designed around it, and really should be done through smart pointers if someone ever attempts it rather than trying to manually re-implement it using load-count-in/decrementation.
The other way is to go through and invalidate stale indices after every unload. This is potentially a little bit less efficient, but much easier and better to maintain, and none of the sound unloads is in a frame critical path, so let's keep it simple for now.