Hello, we are currently encountering crashes on Android devices. It appears that these issues are not tied to a specific Android OS version or device. Typically, they occur after the application enters the ‘on pause’ mode. Here is the stack trace:
libc +0x609dc __memcpy_a53
split_config.armeabi_v7a.apk +0xb31ec FMOD::Geometry::getUserData
A few questions:
FMOD::Geometry::getUserData, or any calls to FMOD::Geometry in general? If so, can you post snippets of these calls?Debug_Initialize, and see whether this reveals any more information when the crash occurs?_eventInstance->setCallback(&SoundEffectFModEvent::EventCallback, mask);FMOD_RESULT F_CALLBACK SoundEffectFModEvent::EventCallback(FMOD_STUDIO_EVENT_CALLBACK_TYPE type, FMOD_STUDIO_EVENTINSTANCE* event, void * /*parameters*/) {
FMOD::Studio::EventInstance *eventInstance = reinterpret_cast<FMOD::Studio::EventInstance*>(event);
SoundEffectFModEvent* soundEffect = nullptr;
eventInstance->getUserData(reinterpret_cast<void**>(&soundEffect));
...
Apologies for the delayed response.
Are you making any calls to Geometry, not just to user data in general?
What’s the latest Android version the crash occurs on? While we don’t use Google’s Oboe API, there is a known issue (which was scheduled for fixing in Android T) with Oboe where other applications can cause a crash when backgrounded, which sounds like it may be what you’re describing. Does anything described here and in the linked github issue line up with your experience? Fmod crash on android crash stack libaudioclient.so - #12 by jeff_fmod
Thank you for continuing the investigation.
We don’t have any geometry calls.
We are experiencing such crashes on Android 13. As I understand, it means that it’s not connected to the Oboe issue.
I’ve given it another test on my end with an example project that makes use of user user data and event callbacks, but unfortunately I’ve been unable to reproduce the issue. Could I get you to upload your project and a crash stack to your FMOD User profile so I can take a look and try to diagnose the issue? Also, can I get you to provide me with the names of the Android devices, or a selection of them, that the crash occurs on?
We cannot reproduce it ourselves; we only have crash statistics from our crash collector services. So, it’s quite useless to upload any build, I think.
You can find the names of the devices with the highest crash rates, but there are many more. I think this case is not device-specific.
Redmi Note 11 5%
Redmi 10C 2%
Galaxy A12 2%
Galaxy A51 2%
Thanks for the device info, I’d agree that it’s probably not device specific.
Unfortunately, it’s a little difficult to dig into this any further without more information. Given that you’re not making any calls to Geometry::getUserData, it’s likely that the symbols aren’t resolving correctly - if you’re able to provide me with a full crash stack/log and your exact NDK version, I should be able to track down the issue.
We did some research, so I want to share the results with you. I hope it will help you investigate the problem.
The previous callstack seems to be wrong. The correct one looks like this:
#0: libfmod.so+0xd73e8 // seems to be OutputRingBuffer::read( 0xb400007155bca800, 0x0, 0x240, true)
#1: libfmod.so+0xe8df8 // seems to be OutputOpenSL::feederThread
#2: libwilhelm.so`audioTrack_handleMoreData_lockPlay(CAudioPlayer_struct*, android::AudioTrack::Buffer const&) + 136
#3: libwilhelm.so`android::AudioTrackCallback::onMoreData(android::AudioTrack::Buffer const&) + 52
#4: libaudioclient.so`android::AudioTrack::processAudioBuffer() + 3048
#5: libaudioclient.so`android::AudioTrack::AudioTrackThread::threadLoop() + 300
#6: libutils.so`android::Thread::_threadLoop(void*) + 428
#7: libandroid_runtime.so`android::AndroidRuntime::javaThreadShell(void*) + 148
#8: libc.so`__pthread_start(void*) + 212
#9: libc.so`__start_thread + 72
Recently, we made a change in our code. Now, we call _lowLevelSystem->setOutput(FMOD_OUTPUTTYPE_NOSOUND) when the application goes on pause, and _lowLevelSystem->setOutput(FMOD_OUTPUTTYPE_OPENSL) when the application resumes. After this change, this occurs more often. As I mentioned before, it seems that the crash occurs after losing the audio context, suggesting a connection between these two things.
Much appreciated, I’ll consult with the development team and get back to you. Additionally, can I get your exact NDK version from you as well?
Just to clarify, you’re saying that the crash occurs more often after making this change?
Yes, after we added setOutput to NOSOUND and back to OPENSL, crashes occur more often. But maybe it’s just a coincidence. Also, in this version, we changed the NDK version: NDK r23b (23.1.7779620) was upgraded to NDK r25c (25.2.9519653).
After consulting with the development team, it appears that a likely culprit is memory used for resampling not being initialized, seemingly after suspending and resuming.
Could I get you to test using various sample rates and see whether you can reproduce the crash? You can set the sample rate with System::setSoftwareFormat - I suspect it’s likely that when no resampling is required (i.e. the FMOD system’s sample rate matches the device’s sample rate), the crash shouldn’t occur.
We can not reproduce this issue on our side, we have only crash logs from our users. So we are not able to help you with the tests…
No problem, I’ll do some more testing on my end. Thanks again for the additional information.
Unfortunately, the issue still hasn’t been reproducible on my end. If you’re currently not, you may wish to try calling System::mixerSuspend and System::mixerResume when suspending and resuming instead of changing the system output type, and see whether that reduces occurrences of the crash. Otherwise, if you’re find or are able to provide any more information on the crash in the future, please feel free to let me know.
We have System::mixerSuspend/System::mixerResume calls in our code. It goes like this:
Suspending:
setOuput(FMOD_OUTPUTTYPE_NOSOUND)
mixerSuspend()
Resuming:
mixerResume()
setOuput(FMOD_OUTPUTTYPE_OPENSL)
We were forced to add setOuput() because you have another bug, it appears mostly on Samsung devices. There is a small sound during the termination of application. I’ve uploaded video to my profile, you can check it there.
Thanks for uploading the video, I can see what you’re referring to and it’s not what we’d expect. I’ll give it a test on a Samsung device on my end soon and see whether I’m able to pin down what’s causing the issue.
Thank you. Also, please check our calls sequence—is it safe, or does it risk causing the initial topic’s crash?
I haven’t been able to reproduce the behavior in your video on my end, so I suspect it may be an issue with how suspending/resuming is being handled on your engine’s side of things. Could I get you to upload a build of your app to your FMOD user profile so I can have a look?
As far as I can tell, no, setting outputs shouldn’t risk causing the initial topic’s crash.
Done, you can check it now.