Using FMOD 1.10.7 7/4/2018
Low Level API in C++
Recently started having some random crashes during ->update(); doesn’t happen often. Three examples from the Windows Event log:
Unhandled exception at 0x000007FED62DD1B8 (fmod64.dll) in .exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF. occurred
Unhandled exception at 0x000007FED612D1B8 (fmod64.dll) in .exe: 0xC0000005: Access violation reading location 0x0000000000000025. occurred
Unhandled exception at 0x000007FED610D1B8 (fmod64.dll) in .exe: 0xC0000005: Access violation reading location 0x0000007B0000007A. occurred
What might cause this?
Fortunately, this is raised as a software error, so right now, I can enclose the ->update() call in a try/catch. If I simply log, ignore the error, and allow things to continue, I’ve not seen any ill effects and ignoring does not seem to increase the frequency of occurrence…still just occasional among many game loops.
Are you able to send us the log, while using the logging libs, to support@fmod.com
1 Like
Sure.
Is it just a matter of linking the lib and using the “L” .dll, or do I also need to set any sort of the debug information, such as with Debug_Initialize?
Never mind, I got the logging figured out and am getting a file. I will reproduce the error and send the log.
I did send logs, but here is a situation update after much experimentation.
Might be some sort of race condition. I noticed this only seems to occur during update() shortly after createSoundInternal for the one type of sound I use a callback for end of track – the music, and often with Starvation detected in WASAPI output buffer…but some internet poking did not much help me figure out that particular message.
Anyway, this doesn’t occur often but I started to notice it was coinciding with music track end and I could reliably reproduce within a few minutes if I load certain music/scenarios (e.g. a music track with a fair amount of silence toward the end of the track, just before actually finishing, with many other one-shots going on during music track end). After much experimentation, I also noticed that during my game loop, during a method RunStart (occurs before where the game loop will call ->update), I investigate isPlaying and if the sounds (including music) are not playing, there is code to release the sound. After playing with this quite awhile, I started to suspect that my code to check isPlaying (perhaps silence at the end is interpreted as not playing?), and if not, releasing the sound was perhaps sometimes stomping a piece of memory that an FMOD thread had already investigated in its internal machinations, I release, causing some further internal memory free within FMOD for a sound, then a fraction later, the FMOD thread tries to read some part of what used to be valid that split second before my release, but while FMOD was iterating some internal logic pertaining to what was once valid at the beginning of its update process in perhaps a separate thread?, and boom.
I changed to only release if I know this sound is not involved in my callback (i.e. non-music), thereby letting the callback fire during ->update. My callback will get some userdata, call another one of my methods to launch up another channel/sound, and it will take care of the release of any existing sound for these particular music sounds, instead of that RunStart check, for just these types.
This seems to work out…I could usually reproduce this problem within minutes, but now, after trying to reproduce for 25 minutes, I’ve not seen the problem.