Community Q&A

Where Wwise users help each other out!

Audiokinetic's Community Q&A is the forum where Wwise users ask and answer questions within the Wwise community. If you would like to get an answer from Audiokinetic's Technical support team, make sure you use the Support Tickets page.

Intermittent crash on Nintendo Switch with Unity

0 votes
We are experiencing intermittent crashes on Nintendo Switch with Unity (2019.1.0f2) . It happens around 50% of the time on first boot - before the Unity logo appears. Removing reference to WWise stops the crash. It's not occurring on our xbox, ps4 and Windows builds. WWise version is 2019.1.1.6977.

Most of the threads are stuck on WaitProcessWideKeyAtomic.
Appreciate any ideas on what might be causing the issue, thanks
asked Sep 3, 2019 in General Discussion by Mark B. (100 points)
reshown Sep 19, 2019 by Mark B.

1 Answer

0 votes
firstly this does not look like a crash but rather a deadlock - crash implies a thread did something which has caused the execuation to abort - deadlock implies that a thread is doing something which prevents one or more other threads from progressing.

both of the callstacks you share are dealing with a mutex that is protecting an allocator that the switch file system is using. the top thread is trying to deallocate memory and waiting for the mutex to become available. the bottom thread is trying to allocate memory and waiting for the mutex to become available. so the answer lies elsewhere.. what I can say with some certainty here is that the mutex that both these threads are trying to acquire is currently locked. next I would look for a thread which hash InternalCriticalSectionImplByHorizon::Enter in an upper frame that isn't waiting to acquire ( not in AbitrateUnlock ).

Just a guess based on your thread names - are you opening a file as Wwise is trying to close it.. is it valid with the nx filesystem to do that?

ps. you probably shouldn't post what could be details of the inner workings of the NX, unless your NDA with nintendo lets you do that, in future :)
answered Sep 7, 2019 by Dan M. (2,660 points)
Thanks for your feedback. Changing the Script Execution Order so the AKInitializer is at the top seems to fix it - I wasn't able to find out exactly why it was happening.

I have removed the details of the NX call stack - but thought I'd leave this up in case it's useful to others.

Thanks again - much appreciated.
ok so we can surmise that code in AKInitialzer needs to be run to initialize something before you use it - could be memory, filesystem, who knows.

> I have removed the details of the NX call stack - but thought I'd leave this up in case it's useful to others.

thanks!
...