Months later I’m tracking down a rare crash, which still occurs in standalone Unity builds. The crash is “pure virtual function call” and the original old thread is here Hard crash in Unity - pure virtual function call.
I managed to get a crash dump from a build and using the symbols from fmod I now have the following callstack.
fmodstudioL.dll!abort() Line 88 C
fmodstudioL.dll!_purecall() Line 57 C
fmodstudioL.dll!FMOD::BusInstance::removePlayingEvent(FMOD::EventInstance * instance) Line 871 C++
fmodstudioL.dll!FMOD::EventInstance::stop(FMOD::EventInstance::StopMode stopMode, bool restarting) Line 290 C++
fmodstudioL.dll!FMOD::EventInstance::update(float deltaSeconds) Line 608 C++
fmodstudioL.dll!FMOD::EventInstanceContainer::update(float deltaSeconds) Line 182 C++
fmodstudioL.dll!FMOD::PlaybackSystem::update(FMOD::TimeStamp * owningTimestamp, bool alreadyCachedClocks) Line 1034 C++
fmodstudioL.dll!FMOD::RuntimeAPI::Manager::update(FMOD::TimeStamp * owningTimestamp, bool cacheClocks) Line 216 C++
[Inline Frame] fmodstudioL.dll!FMOD::AsyncManager::asyncProcessAndUpdate() Line 768 C++
fmodstudioL.dll!FMOD::AsyncManager::asyncThreadLoop() Line 802 C++
fmodstudioL.dll!FMOD::callback(void * data) Line 56 C++
fmodstudioL.dll!FMOD_OS_Thread_Callback(void * param) Line 537 C++
fmodstudioL.dll!_callthreadstartex() Line 354 C
fmodstudioL.dll!_threadstartex(void * ptd) Line 332 C
unfortunately that is where the trail ends for me as I don’t have access to source. Is there someone who can give some insight into what removePlayingEvent is trying to do? Obviously I’m all on the managed side of code in Unity, but if anyone at FMOD recognizes this callstack or could give me a hit of how this can occur I would be very grateful.
Are you able to share your dmp file and any log files you may also have so that we can try to debug it here? You can upload the files to https://fmod.com/profile#uploads.
unfortunately it is very difficult to reproduce. we suspect it has something to do with an FMOD.Studio.EVENT_CALLBACK but cannot be certain. Is there someplace we can share some code, that isn’t on the forum? It would be helpful for an engineer to take a look at our event callback code and see if there is something we are doing out of order.
Screen sharing is also an option. The crash is sporadic and unfortunately not rare enough for us to ignore further
Here is what we are doing. We have a class AudioTimelineEventListener. It has a single instance and owner. In turn this class creates one instance of an AudiotTimeLineInfo class, which is marked as sequential. It has a couple of int members only. Now on some game event, we call Init, which sets the timelinehandle as user data on an eventInstance and then sets the callback.
When we no longer want a beat callback on this instance, we call
eventInstance.setCallback(null);
eventInstance.setUserData(IntPtr.Zero);
Init can be called several times during a play session, (essentially when we switch music). Before we set user data and callback, any old instance which has been playing has callback set to null and userdata to zero.
Is it safe to keep this AudioTimelineInfo and timelineHandle alive (and pinned) for the entire lifetime of the game but simply assign our callback to new event instances or does this method require us to allocate a new handle whenever we assign a parameter to a new event instance?
:callback(void * data) Line 56 C++
