getUserData android crash

FMOD Engine
1

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

2

A few questions:

  • What version of FMOD (and relevant engine, if you’re using an official integration) are you using?
  • Are you making any calls to FMOD::Geometry::getUserData, or any calls to FMOD::Geometry in general? If so, can you post snippets of these calls?
  • If you haven’t already, can you swap to the logging version of the libs (“L” suffix), enable logging with Debug_Initialize, and see whether this reveals any more information when the crash occurs?
  • Can I get you to post the full stack trace and any relevant logs? You can post them here, or upload it to your FMOD user profile.
3
  1. 2.02.19, we have our custom engine.
  2. We have such process to call getUserData():
    at the begining:
    _eventInstance->setCallback(&SoundEffectFModEvent::EventCallback, mask);
    later call from your API:
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));
...
  1. We can not switch to logging version because we have found these issues only in production logs of the application.
  2. It’s full stack trace, we don’t have anything more and there are no usefull logs.
4

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

5

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.

6

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?

7

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%

8

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.

9

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.

10

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?

11

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).

12

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.

13

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…

14

No problem, I’ll do some more testing on my end. Thanks again for the additional information.