Hello there,
We’ve been receiving a few dozens of crashes regarding a crash from our audio thread in Shipping builds. It remains an isolated case with only 20 users but the callstacks arethe same.
The lack of logs and context is making it hard to reproduce and fix. I took a look at the engine code especially UpdateKeySourcePatch(). This returns whether the current patch is valid but I can also see this comment stating this should be called during Teardown:
However, we clearly are in a Teardown context from the GameThread. So, isn’t there something going wrong already here?
I assume the bPatchIsValid boolean from FSubmixEffectDynamicsProcessor::OnProcessAudio() fails to return what we expect, therefore makes us access a cleaned up memory address.
Most of the currently reported audio crashes are about audio device swap. I tried to spam an audio device swap (with different number of channels) on my end with no luck. Also, we added this other fix a few weeks ago to prevent the number of input channels being swapped:
[Content removed]
I wanted to check up if there were any obvious leads to think of for this type of issue 
Best,
Guillaume
Sorry for the delayed response here. I did some digging.
We have implemented one fix to that system which may be what you’re hitting. It was rare and had to do with updating keys to the dynamics processor. The code is updated in our main branch, but hasn’t made it out yet on any official releases. Here’s a screenshot of the code diff in case you want to try implementing it yourself.
Best,
Phil P
Hi Phil,
Thanks for your answer, as I stated above, we already had this fix in when the crash happened. Do you think there could be another sensitive code causing this type of crash?
Best,
Guillaume
Ah, I hadn’t looked at the prior conversation you had. I don’t see any threading protections for accessing the FSubmixEffectDynamicsProcessor::KeySource leading to possible data race conditions come from the rendering callstack and the OnDeviceDestroyed callstack.
The hack fix is to probably just throw some critsec around that one or utilizing the FSoundEffectDynamicsProcessor::EffectCommand(…) to have the reset get called on the audio render thread.
If you have any more callstacks for the crash, I can take a deeper look. But if it’s all on shutdown related, I would be on it being related to that. Interestingly enough, our FAudioDevice layer does not teardown due to device swaps. If you’re seeing something that occurs at a conjunction of teardown and device swap, I’d probably have to look at some callstacks and logs to get an idea of what’s going wrong. Currently we’re not hitting this issue in any of our uses.
Cheers,
Phil
