we’re using the lowlevel C++ fmod SDK for our iOS and Android game for quite a while already.
We updated to the latest SDK with our last update, hoping that the crashes would be gone - but no luck so far.
Crashlytics shows us that there’s crashes happening that seem to be connected to FMOD and it’s crashing in a “FMOD_OS_Semaphore_Wait(FMOD_OS_SEMAPHORE*)”
We attached some screenshots from Crashlytics and hope you can help us on this.
The crash isn’t actually occurring here it just does not have the symbol for where the crash is, it is actually + 105988 from that symbol. If you are able to reproduce it yourself, while using the logging libraries, it should provide a lot more accurate information.
Okay, I understand - but unfortunately, we’re not able to reproduce it. We’re using Crashlytics (and soon Bugsnag) to detect crashes and get symbols+stacktraces. Is there a way to have access and upload the FMOD symbols? Would making a live build with the debug/logging libraries do the trick to find these crashes in this case?
By using the logging libraries you will have access to the FMOD symbols, just make sure to call FMOD::Debug_Initialize and set the logging level to FMOD_DEBUG_LEVEL_ERROR otherwise it will end up logging a lot of unneeded information.
@cameron-fmod Okay, great. I will try this. Just to be sure: The output dsym file of the Xcode build, will then just contain the symbols, right?
Is it possible to re-route the FMOD logs to our own logging (and to push it into Crashlytics). That would help to provide a stacktrace + logs and hopefully help to fix this.
So it turns out that for iOS the release and debugging libs contain the same symbols which is none, due to them being static libs. We do have plans to change over to using dylibs but that is still a couple of months away at a minimum. Apologies for the confusion.
So it looks like logging is your best bet at this point and logging requires the debug lib. One of the parameters for Debug_Initialize is FMOD_DEBUG_MODE which is for specifying the destination of the log output when using the logging version of FMOD.
@cameron-fmod thanks for the idea with the debugging lib! I tried this and we even released an update with it, to see if new logs appear. Unfortunately, there’s no new logs in the crashlytics-crash-log, that are from FMOD_ERROR.
I found out something interesting though: It seems like all these crashes come from older devices: iPad 3, iPad 4, iPad Mini. Maybe this gives you any idea what might happen?
Also here’s a crashlytics-stacktrace-txt file - maybe this helps to figure out where it crashes exactly (since you have access to the symbols) and additionally also a screenshot of the stacktrace in Crashlytics that might indicate that 2 FMOD threads are waiting for each other / give some hints for the semaphore crash.
The callstacks provided don’t appear to be in a bad state, the FMOD stream thread is waiting on a sleep and the FMOD mixer thread is waiting on a semaphore wait trap, these are both valid.
@cameron-fmod We integrated Bugsnag now (working better than Crashlytics to get accurate stacktraces). Therefore, we now have another stacktrace of the fmod-related crashes that our users are facing at the moment. It seems like it’s happening when the app enters the foreground again. Do you have any idea what could cause this and what we could do against it?
Could it cause issues to call mixerResume() while still loading audio files or anything similar?
Depending on the AudioCategory used, it may be caused by mixerResume being called from applicationWillEnterForeground instead of applicationDidBecomeActive. Trying to call into FMOD while it is still in the background would result in a failure as it is not allowed to run in the background.
