getUserData iOS crash

Hi!
We are currently encountering crashes on iOS devices only, 3% of our players encountering it.
It appears that this issue is tied to a specific state: 100% of devices are in background state. Most of crashes are on iOS 18+, near 10% are iOS 16+
The FMOD version is 2.02.19
Thank you in advance!

Here is the stack trace:

Crashed: FMOD Studio update thread

EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x00000000001f4bbc

Crashed: FMOD Studio update thread
0  UnityFramework                 0x3d3d2a4 FMOD_Studio_CommandReplay_SetUserData + 404064
1  UnityFramework                 0x3d3d298 FMOD_Studio_CommandReplay_SetUserData + 404052
2  UnityFramework                 0x3d42c58 FMOD_Studio_CommandReplay_SetUserData + 427028
3  UnityFramework                 0x3d3a394 FMOD_Studio_CommandReplay_SetUserData + 392016
4  UnityFramework                 0x3d8ec70 FMOD_Studio_CommandReplay_SetUserData + 738348
5  UnityFramework                 0x3d11460 FMOD_Studio_CommandReplay_SetUserData + 224284
6  UnityFramework                 0x3d29838 FMOD_Studio_CommandReplay_SetUserData + 323572
7  UnityFramework                 0x3d288d8 FMOD_Studio_CommandReplay_SetUserData + 319636
8  UnityFramework                 0x3d29c50 FMOD_Studio_CommandReplay_SetUserData + 324620
9  UnityFramework                 0x3e9d49c FMOD5_Reverb3D_GetUserData + 645312
10 UnityFramework                 0x3e7dde8 FMOD5_Reverb3D_GetUserData + 516620
11 libsystem_pthread.dylib        0x3344 _pthread_start + 136
12 libsystem_pthread.dylib        0xab8 thread_start + 8

Hi,

Thanks for the call stack and info.

There was an addition in 2.02.24 that suspends the mixer on all threads: FMOD Engine | Detailed Revision History. Suspending the mixer will reduce the CPU usage to 0% while maintaining FMOD state: FMOD Engine | Core Api System - System::Mixersuspend. We have also added some more docs here for how to use the suspend/resume functions: FMOD Engine | Platforms Ios - Suspend In Background.

Could I also please grab your Unity version?

Hi!
Thank you for your quick response!

The Unity version is 2022.3.49f1

Do you mean the FMOD version 2.02.19 could leave to such kind of crash?
Do you have any idea how to reproduce the crash?

Thank you for the version.

Unfortunately, I was not able to reproduce the issue with a simple test of back-grounding a Unity app. Was there any more information about what your users where doing while the app was in the background? Changing output device, locking or unlocking and maybe another form of interruption?.

I am not sure of the exact cause of the crash currently.

Hi Connor!

Unfortunately we do not have additional info about users’ behaviour in that state, as the crashlytics don’t send it to us

No idea, either

1 Like

Ok, thanks for the info. Are the call stacks the same ever time? Are there any logs or crash dumps that you can share?

Hi Connor!

Call stacks are same, yes. Unfortunately there are no crash dumps to get.
By the way, it seems the

RuntimeManager.Initialize() ->RegisterSuspendCallback(HandleInterrupt);

does nothing. Somehow the

private static void HandleInterrupt(bool began)

is never called by switching background state and foreground.

Is it possible we did something wrong here? Maybe we’ve missed some settings?

What is the current behavior of the app when being backgrounded?

If we add debug logs to the callback are you able to see those?

#if (UNITY_IOS || UNITY_TVOS) && !UNITY_EDITOR
[AOT.MonoPInvokeCallback(typeof(Action<bool>))]
private static void HandleInterrupt(bool began)
{
    if (Instance.studioSystem.isValid())
    {
        // Strings bank is always loaded
        if (Instance.loadedBanks.Count > 1)
            PauseAllEvents(began);

        Debug.Log($"In the callback entering background={began}");

        if (began)
        {
            Instance.coreSystem.mixerSuspend();
        }
        else
        {
            Instance.coreSystem.mixerResume();
        }
    }
}
In the callback entering background=True
FMODUnity.RuntimeManager:HandleInterrupt(Boolean)

In the callback entering background=False
FMODUnity.RuntimeManager:HandleInterrupt(Boolean)

This should be handled by FMOD for you without any changes being made to the settings.

If we add debug logs to the callback are you able to see those?

I did the same, and there is no log there. I mean it, the private static void HandleInterrupt(bool began) would just not be called
I made a workaround with unity’s Application.focusChanged += NewFuntionInRuntimeManager and mixerSuspend() / mixerResume() are called now. But it’s a bit ugly

Thanks for the info.

Can I confirm, before your change when the app was backgrounded the audio would continue to play or would it stop?

For sure, Connor!

In both cases (without custom fix and with it) sound stopped to play and started again as soon as i switched back to the game

But we don’t know exactly the behavior in case crash happened

Thank you for the conformation.

There have been some fixed in recent versions for detecting if the app focus has been changed. Would it be possible to test updating the integration to check if it is correctly logging when entering the background?