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:
[code:19104ddt]
FMOD_RESULT res = sgpSystem->createSound(szFile, FMOD_MODE(nMode), NULL, &pSound);
if(res != FMOD_OK)
{
if(pSound)
{
pSound->release();
}
// Show a data warning, continue the loop, etc.
}
[/code:19104ddt]

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.