I’ve recently implemented the FMOD::Memory_Initialize() function call with wrappers into our own alloc/realloc/free memory management functions. I discovered by doing that that sounds created with System::Create() are not freed when you do a System::release(), and that you have to do a Sound::release() explicitly.
Which is fine; I just didn’t know that before now 😀
However, once I implemented code to release() all of the Sound objects, there still remained one nasty memory leak reported at the end through the sound memory callback wrappers. This memory leak I tracked down to some incorrect data in our sound file reference, which was building an invalid filename. The line looks like this:
FMOD_RESULT res = sgpSystem->createSound(szFile, FMOD_MODE(nMode), NULL, &pSound);
if(res != FMOD_OK)
// Show a data warning, continue the loop, etc.
Now, when szFile contains a legitimate path, this allocates the memory for pSound and then I store off the resulting pointer and release it later on in life. However, when szFile is NOT a valid file, res gets set to FMOD_ERR_FILE_NOTFOUND, pSound remains NULL, but some memory is still allocated! Specifically, there is a 2064-byte allocation happening somewhere in there.
So, to summarize, I’m using FMOD::Memory_Initialize() with alloc/realloc/free, calling System::createSound() with an invalid filename such that it returns file not found, and there are 2064 bytes left over.
So, there it is. Thank you!
- Adiss asked 13 years ago
No, it probably isn’t — that little bit of code I put in while trying to track this problem down. The original didn’t have the pSound->release() on failure.
Thanks, though! I’ll remove the offending piece of code, and assure the other programmers that the memory leak will go away with a new version.
Please login first to submit.