FMOD memory management crash

Currently waiting on a response from unity support, but figured it’d be worth floating this out on the forum as well in case the community has any input on the issue.

Had a number of crashes lately that we thought were related to a native dialogs plugin (based on when they occurred). However it seems that these (and a few other crashes) are actauly not the dialogs in themselves, but an issue with FMOD. The crash logs seem to show a couple of calls to an FMOD function just before the crash. The thread0 for the crash log is as follows.

Exception Type:  EXC_BAD_ACCESS (SIGABRT)
Exception Subtype: KERN_INVALID_ADDRESS at 0x00000e3c
Triggered by Thread:  0

Thread 0 Crashed:
0   libsystem_kernel.dylib        	0x39d201fc __pthread_kill + 8
1   libsystem_pthread.dylib       	0x39d89a2e pthread_kill + 54
2   libsystem_c.dylib             	0x39cd0ff8 abort + 72
3   realscaryspiders              	0x01b37210 FMOD::CodecFSB5::getMemoryUsedImpl(FMOD::MemoryTracker*) + 1436076
4   realscaryspiders              	0x01b26b68 FMOD::CodecFSB5::getMemoryUsedImpl(FMOD::MemoryTracker*) + 1368836
5   libsystem_platform.dylib      	0x39d84060 _sigtramp + 40
6   StoreKit                      	0x3173b0e6 __34-[SKProductsRequest _handleReply:]_block_invoke + 442
7   libdispatch.dylib             	0x39c44d78 _dispatch_call_block_and_release + 8
8   libdispatch.dylib             	0x39c44d64 _dispatch_client_callout + 20
9   libdispatch.dylib             	0x39c4b7bc _dispatch_main_queue_callback_4CF$VARIANT$mp + 264
10  CoreFoundation                	0x2effe81c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 4
11  CoreFoundation                	0x2effd0f0 __CFRunLoopRun + 1296
12  CoreFoundation                	0x2ef67ce2 CFRunLoopRunSpecific + 518
13  CoreFoundation                	0x2ef67ac6 CFRunLoopRunInMode + 102
14  GraphicsServices              	0x33c5527e GSEventRunModal + 134
15  UIKit                         	0x31809a3c UIApplicationMain + 1132
16  realscaryspiders              	0x000581fc _mh_execute_header + 16892
17  libdyld.dylib                 	0x39c69ab4 start + 0

This same pattern of the FMOD calls followed by the abort and thread kills is in all of the related crash logs for these issues. These crashes currently happen at two key moments, one is when a native dialog is closed and context switches back to the unity application. The other is on launch of the application (our testers bug report says that this occurs if you close the game during the splash screen, force close it from the process bar and then re-launch)

We’re trying to test removing audio to see if we can still recreate the bug then, but so far its been a difficult issue to consistently reproduce every time which is making it hard to work out.

So has anyone else seen this sort of error? or have any input on the issue in general?

Edit:
Stopping audio before the dialogs, and resuming it on dialog completion seems to have greatly reduced the crashing, however more crash logs have come through from swapping the app via multi-tasking gestures, returning to the app like this has also caused crashes which like the previous ones, seem to point to the same FMOD calls to getMemoryUsedImpl
This issue is starting to become a serious pain has nobody else come into contact with this?
Edit 2:
Ok this error is getting out of hand now. Crash logs now show the same pattern of calls to FMOD::getMemoryUsedImpl() immediately followed by the abort and kill messages for the following crash reports.
- On Closing native dialogs (only sometimes, only on some devices).
- On switching back to the app from other apps (only sometimes, some devices.)
- On entering our augmented reality scene (only observed a few times).
- Close application from process bar + relaunch (crashed on launch from some devices)
As far as I can tell we aren’t doing anything fancy with audio, we have a background track playing, and a number of other sounds that are triggered at various points. Music is played set as Compressed OggVOrbis compressed on disc. the sound effects are all set as native WAVs loaded into memory. If this is the wrong way to do it then that’s fine, but I’d love to know what to change, and why it isn’t consistent.

Did you find any solution to this problem?