I have crashes for version 2.00.08. Below are stacktraces of crashed threads. I can not reproduce it localy but my application users have it a lot of times. There is no special activity in main thread that uses FMOD at the moment of crash. Do you have ideas how to solve it?
And one more question. Is it ok if I don’t use any CommandReplay functions but there are such calls inside FMOD threads?
iOS:
Thread 10:
0 ??? 0x0000000000000001 0x0 + 0
1 f 0x0000000102162ff4 FMOD_Resampler_Linear + 510908
2 f 0x0000000102164108 FMOD_Resampler_Linear + 515280
3 f 0x0000000102173740 FMOD_Resampler_Linear + 578312
4 f 0x0000000102177390 FMOD_Resampler_Linear + 593752
5 f 0x000000010217e584 FMOD_Resampler_Linear + 622924
6 f 0x0000000102130a98 FMOD_Resampler_Linear + 304736
7 f 0x0000000102131bdc FMOD_Resampler_Linear + 309156
8 f 0x00000001020a2818 FMOD:
:callback(void*) + 144
9 f 0x0000000102081b0c FMOD_OS_Thread_Callback(void*) + 72
10 libsystem_pthread.dylib 0x00000001aa571d98 _pthread_start + 152
11 libsystem_pthread.dylib 0x00000001aa57574c thread_start + 4
Android:
Thread 51:
0 0xf3836d30 + 306480
r0 = 0x00000000 r1 = 0x00002b84
r2 = 0x00000006 r3 = 0x00000008
r4 = 0xc6932978 r5 = 0x00000006
r6 = 0xc6932920 r7 = 0x0000010c
r8 = 0x00000000 r9 = 0x0a0f1800
r10 = 0xc69324b8 r12 = 0x00000000
fp = 0xc33132c8 sp = 0xc6932408
lr = 0xf38344c7 pc = 0xf3836d30
1 0xf3809d9b + 122267
sp = 0xc6932420 pc = 0xf3809d9d
2 0xf3805523 + 103715
sp = 0xc6932428 pc = 0xf3805525
3 0xf3803162 + 94562
sp = 0xc6932450 pc = 0xf3803164
4 0xf2a815fd + 9725
sp = 0xc6932458 pc = 0xf2a815ff
5 0xf2a80edd + 7901
sp = 0xc6932464 pc = 0xf2a80edf
6 0xf2a80ed3 + 7891
sp = 0xc6932468 pc = 0xf2a80ed5
7 0x3caec33c + 166642492
sp = 0xc69324e4 pc = 0x3caec33e
8 0x3caec33c + 166642492
sp = 0xc6932504 pc = 0x3caec33e
9 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc04e377]
sp = 0xc693253c pc = 0xcc04e379
10 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc04e97f]
sp = 0xc6932560 pc = 0xcc04e981
11 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc04e97f]
sp = 0xc6932598 pc = 0xcc04e981
12 JNI_OnLoad [0xcc0f8ee7]
sp = 0xc69325a0 pc = 0xcc0f8ee9
13 FMOD::SystemI::createDiskFile(char const*, FMOD_CREATESOUNDEXINFO*, FMOD::File**, bool*) [0xcc098df9]
sp = 0xc69325a8 pc = 0xcc098dfb
14 FMOD_Memory_GetStats [0xcc075849]
sp = 0xc69325c0 pc = 0xcc07584b
15 JNI_OnLoad [0xcc0f8ef7]
sp = 0xc69325d8 pc = 0xcc0f8ef9
16 FMOD::SystemI::createDiskFile(char const*, FMOD_CREATESOUNDEXINFO*, FMOD::File**, bool*) [0xcc098e17]
sp = 0xc69325e0 pc = 0xcc098e19
17 FMOD_Reverb3D_GetUserData [0xcc076b21]
sp = 0xc69325e8 pc = 0xcc076b23
18 FMOD::Channel::getPosition(unsigned int*, unsigned int) [0xcc0e4ac3]
sp = 0xc69325f8 pc = 0xcc0e4ac5
19 FMOD::ChannelControl::getDSPClock(unsigned long long*, unsigned long long*) [0xcc0e6347]
sp = 0xc6932600 pc = 0xcc0e6349
20 FMOD::ChannelControl::getDSPClock(unsigned long long*, unsigned long long*) [0xcc0e6347]
sp = 0xc6932608 pc = 0xcc0e6349
21 FMOD::ChannelControl::getDSPClock(unsigned long long*, unsigned long long*) [0xcc0e6347]
sp = 0xc6932618 pc = 0xcc0e6349
22 FMOD::AsyncThread::getAsyncThread(FMOD::SystemI*, int, FMOD::AsyncThread**) [0xcc07cd5d]
sp = 0xc6932628 pc = 0xcc07cd5f
23 FMOD::ChannelControl::getDSPClock(unsigned long long*, unsigned long long*) [0xcc0e6347]
sp = 0xc6932648 pc = 0xcc0e6349
24 FMOD::System::getMasterChannelGroup(FMOD::ChannelGroup**) [0xcc0f259d]
sp = 0xc6932650 pc = 0xcc0f259f
25 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc03c175]
sp = 0xc6932660 pc = 0xcc03c177
26 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc04ebb7]
sp = 0xc6932698 pc = 0xcc04ebb9
27 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc03469b]
sp = 0xc69326c0 pc = 0xcc03469d
28 0xf14826a9 + 2569897
sp = 0xc69326c8 pc = 0xf14826ab
29 0xf144cc97 + 2350231
sp = 0xc69326d0 pc = 0xf144cc99
30 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc04e377]
sp = 0xc6932710 pc = 0xcc04e379
31 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc03e331]
sp = 0xc6932728 pc = 0xcc03e333
32 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc04e377]
sp = 0xc693277c pc = 0xcc04e379
33 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc04e97f]
sp = 0xc6932780 pc = 0xcc04e981
34 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc033e9f]
sp = 0xc6932798 pc = 0xcc033ea1
35 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc034771]
sp = 0xc69327b0 pc = 0xcc034773
36 0xf1630447 + 4330567
sp = 0xc69327d4 pc = 0xf1630449
37 0xf1630478 + 4330616
sp = 0xc69327d8 pc = 0xf163047a
38 0xf162f846 + 4327494
sp = 0xc69327dc pc = 0xf162f848
39 0xf1540173 + 3346803
sp = 0xc69327e0 pc = 0xf1540175
40 0xf3853c7d + 425085
sp = 0xc6932880 pc = 0xf3853c7f
41 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc04e377]
sp = 0xc6932884 pc = 0xcc04e379
42 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc04e97f]
sp = 0xc6932888 pc = 0xcc04e981
43 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc04e3e9]
sp = 0xc69328c8 pc = 0xcc04e3eb
44 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc04e9f5]
sp = 0xc69328d8 pc = 0xcc04e9f7
45 0xf3833f7b + 294779
sp = 0xc6932904 pc = 0xf3833f7d
46 0xf3833f93 + 294803
sp = 0xc6932910 pc = 0xf3833f95
47 0xf3806161 + 106849
sp = 0xc6932918 pc = 0xf3806163
48 FMOD::Studio::CommandReplay::setUserData(void*) [0xcc04e97f]
sp = 0xc6932954 pc = 0xcc04e981
Hi maksimomelyanchuk,
Is there any chance you could upgrade your fmod version to 2.00.09? For android, it will help us get more information from your callstack. The current android callstack translation looks like it is inaccurate (it’s unlikely that FMOD::Studio::CommandReplay::setUserData is actually being called in that manner).
Also, are there any logs with the crashes?
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.