FMOD crash on Android and iOS

I will update fmod version, but it will be not fast.
There are logs but there is nothing inside about fmod or other audio connected errors, I’ve checked.
Do you have any ideas about reasons of the crashes on Android or iOS with current information?

Unfortunately there’s not alot for me to go on here. Even the resampler function isn’t setup to be recursive, so that call stack doesn’t provide any insights. Are all the callstacks similar? Do you have any other information that might be useful?

Hi maksimomelyanchuk,

In 2.00.10 we released yesterday, we have fixed a crash that resembles this crash. Hopefully upgrading to that version resolves your issue.

Hi,
Thank you for the update. Is it ok to use 2.01.02 version or it’s better to prefer 2.00.10?

Both versions have the fix, they are different major versions.

We can make behaviour changes between major versions behaviour changes between major versions, but not minor versions. If you are currently on 2.00.08, the question of whether to use any 2.01.xx version would depend on your projects release and testing requirements.

I mean that 2.01.xx versions are tagged with “Early access”, so are they ready to be used in real applications or they are still in test stage on your side?

We generally have major versions under the early access label for a few versions so that we can be more confident in the stability of the releases. We still perform our testing on early access releases, but we generally dissuade games that are about to release from moving on to an early access version unless there is a specific reason to do so.

It is better for new games or games with release dates that are further away to move on to the early access version.

Hi again,
We have updated to 2.00.10 version. iOS crashes have dissappeared, thank you. But we still have a lot of crashes on Android. Please take a look at it as soon as it possible. There are such stack traces:
1.
* libfmod.so
JNI_OnLoad
* libfmod.so
Java_org_fmod_FMOD_OutputAAudioHeadphonesChanged
* libfmod.so
Java_org_fmod_FMOD_OutputAAudioHeadphonesChanged
* libfmod.so
FMOD5_Reverb3D_GetUserData
* libfmod.so
FMOD5_Reverb3D_GetUserData
* libfmod.so
FMOD::SystemI::createDiskFile(char const*, FMOD_CREATESOUNDEXINFO*, FMOD::File**, bool*)
* libfmod.so
FMOD::System::update()
* libfmodstudio.so
0xa1d9fd14 + 314644
* libfmodstudio.so
0xa1da7f88 + 348040
* libfmodstudio.so
FMOD::Studio::CommandReplay::setUserData(void*)
* libfmodstudio.so
FMOD::Studio::CommandReplay::setUserData(void*)
* libfmodstudio.so
FMOD::Studio::CommandReplay::setUserData(void*)
* libfmodstudio.so
FMOD::Studio::CommandReplay::setUserData(void*)

    • libc.so
      0xa89983cc + 295884
    • libfmod.so
      Java_org_fmod_FMOD_OutputAAudioHeadphonesChanged
    • libfmod.so
      Java_org_fmod_FMOD_OutputAAudioHeadphonesChanged
    • libfmod.so
      FMOD::SystemI::setInternalCallback(int, FMOD_RESULT ()(FMOD_SYSTEM, unsigned int, void*, void*, void*), void*)
    • libfmod.so
      FMOD::System::mixerSuspend()

Glad to hear that iOS is fixed.

The call stacks are somewhat corrupted, so I’ll need some more information to try and understand what’s happening.

When are you calling mixerSuspend/mixerResume? Is it possible that you would also be creating/destroying/initializing an FMOD System at the same time?

Do you have any other information on when the crash is occuring?

Inside native thread that called from main activity onPause()/onResume() methods.

No, it’s not possible.

We can not catch it localy, we have only crashes from our users in AppCenter.

Do you happen to have the full logcat output? There’s not much we can do with the callstacks as is, but we might be able to get a better translation of the callstack by using the original logs.

No, we don’t have such logs. I have only just little part:
: PlayerBase::stop() from IPlayer
AudioTrack: stop() called with 11455104 frames delivered
AAudio : AAudioStream_requestStop(0x75c3846600)

All I can do is to give you one more crash stack trace, it seems to be not very corrupted.
libc.so 0xc403f8c8 + 493768
libfmod.so JNI_OnLoad
libfmod.so Java_org_fmod_FMOD_OutputAAudioHeadphonesChanged
libfmod.so Java_org_fmod_FMOD_OutputAAudioHeadphonesChanged
libfmod.so FMOD5_Reverb3D_GetUserData
libfmod.so FMOD5_Reverb3D_GetUserData
libfmod.so FMOD::SystemI::createDiskFile(char const*, FMOD_CREATESOUNDEXINFO*, FMOD::File**, bool*)
libfmod.so FMOD::System::update()
libfmodstudio.so 0x227f6d14 + 314644
libfmodstudio.so 0x227fef88 + 348040
libfmodstudio.so FMOD::Studio::CommandReplay::setUserData(void*)
libfmodstudio.so FMOD::Studio::CommandReplay::setUserData(void*)
libfmodstudio.so FMOD::Studio::CommandReplay::setUserData(void*)
libfmodstudio.so FMOD::Studio::CommandReplay::setUserData(void*)
libc.so 0xc403ee9c + 491164

When I say the callstack is corrupted - the functions that have been translated don’t form a valid callstack. There’s no way for those functions to call each other, let alone in that order, so the callstack becomes an untrustworthy data point. The same is true for the other 2 callstacks.

The log entries might be more interesting though - were there any consistencies of the user devices with those callstacks (especially concerning android OS version)?

Hi, sorry for delay.
For 1 callstack android versions are:
8.1.0 68.0%
10 23.7%
9 8.2%

For 2: all crashes on 8.1.0

Hi maksimomelyanchuk,

Thanks for the information. I think we’ve identified a potential fix for the issue that will be included in our next release.

You should be able to work around the issue by setting the output type to OpenSL.

Our partners have permanent crashes on device Black shark2 Pro(https://product.pconline.com.cn/mobile/heisha/1202048.html). We don’t have a lot of info, only this:
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
08-18 10:32:05.473: A/DEBUG(3139): Cause: null pointer dereference
08-18 10:32:05.473: A/DEBUG(3139): x0 0000000000000000 x1 0000007d0477d400 x2 0000007d04600000 x3 0000000000000012
08-18 10:32:05.473: A/DEBUG(3139): x4 000000000000017d x5 0000000000000004 x6 0000007dac4e5010 x7 7f7f7f7fffff7fff
08-18 10:32:05.473: A/DEBUG(3139): x8 0000007d009a2a08 x9 0000000000000001 x10 0000000000004001 x11 0000000000000000
08-18 10:32:05.473: A/DEBUG(3139): x12 000000000000018c x13 ffffffffffffffff x14 ffffffffff000000 x15 ffffffffffffffff
08-18 10:32:05.473: A/DEBUG(3139): x16 0000007d089634d8 x17 0000007da9a1cd78 x18 0000000000000010 x19 0000007d009a2a08
08-18 10:32:05.473: A/DEBUG(3139): x20 0000007d089a4590 x21 0000000000000001 x22 0000000000000002 x23 0000000000000000
08-18 10:32:05.473: A/DEBUG(3139): x24 00000000000002a5 x25 0000007d08e42000 x26 0000007d08ff7588 x27 0000000000000000
08-18 10:32:05.473: A/DEBUG(3139): x28 0000000000000000 x29 0000007d08e62cf0
08-18 10:32:05.473: A/DEBUG(3139): sp 0000007d08e62cf0 lr 0000007d0890d2ec pc 0000007da9a1cd78
08-18 10:32:05.473: A/DEBUG(3139): backtrace:
08-18 10:32:05.473: A/DEBUG(3139): #00 pc 0000000000092d78 /system/lib64/libc.so (pthread_mutex_lock)
08-18 10:32:05.473: A/DEBUG(3139): #01 pc 00000000000c72e8 /data/app/6BiAlOpcKxLiq8ObbuUOQQ==/lib/arm64/libfmod.so

Is it the same problem?

It’s almost impossible to tell from just the 2 line call stack and crash message. I can’t say I’m even entirely sure I know what I’m looking at with this information.

On a long shot on that callstack, are you calling ChannelControl::get3DMinMaxDistance at all?

No, there are no such calls.

Ok, you’ll need to test with the logging version of FMOD. It will produce more accurate callstacks and provide additional information so we can understand what is going on.

We’ve just released 2.00.12/2.01.04 - they should address this crash.