0
0

I’m not sure if I’m the only person to ever run into this issue, but:

In the FMOD_ADVANCEDSETTINGS struct, you can provide a char* to the debug log file name (debugLogFilename). I personally assumed that FMOD internally kept a copy of the string, so it would be safe. So, I gave it a string that was on the stack. FMOD does indeed copy the string internally, however it also keeps around a pointer to this buffer internally in their copy of the FMOD_ADVANCEDSETTINGS struct and around:

fmod_systemi.cpp:5396

they use that pointer and copy the debug log filename back to that address. For me, this resulted in call stack corruption in the debug build of my project.

I fixed it by simply giving it a static buffer instead and everything works fine, since FMOD is free to write to this buffer as much as it wants. I’m guessing most people don’t encounter this because they just provide a static string like debugLogFilename = "whatever.log" so it gets written back over without any problems.

I would recommend that either FMOD not use this pointer in this fashion or that the documentation for this struct be updated to state that FMOD keeps a pointer to the string and writes to it sometimes. =)

  • You must to post comments
0
0

Hi,
I’m really struggling to find where you think it writes to your pointer. FMOD just doesnt do that. It does a strcpy into its own buffer, then never uses it again. Yes the pointer is stored (because fmod just copies the struct you pass to its own copy) but that pointer isnt written to, or read from.

Doing a global search for ‘debugLogFilename’ in fmod’s source only shows it ever being referenced in setAdvancedSettings, and getAdvancedSettings.

setAdvancedSettings refers to it 3 times (2 ifstatements to see if it is null, and one to copy it to our global copy), and getAdvancedSettings referes to it twice (one if statement to see if it is null, another to copy OUR version from our global to your passed in pointer).

There are no ‘writes’ to pointers that are pass in by the user. We always copy.

  • You must to post comments
0
0

Yeah, it’s pretty obscure, but maybe the problem is best summed up as that there is a call to getAdvancedSettings inside the load soundbank code that gets the struct that the user passes in.

in fmod_soundbank.cpp: 1681

this struct is loaded in order to retrieve the event queuesize. However, since the getAdvancedSettings function internally automatically copies the global debugLogFilename setting back to the pointer in the advanced settings struct the user passed in during the initial setAdvancedSettings call, it writes to a potentially unsafe memory address.

Actually, on further inspection, I think I see the problem. In getAdvancedSettings, the settings struct that is passed in contains a NULL as the debugLogFilename, however, that is ignored because before the debugLogFilename is copied, it copies the stored copy of the advanced settings struct the user passed in, which might have a bad pointer by this point.

The more correct version of this function should store the debugLogFilename pointer that was passed in in the settings struct before the memcpy at fmod_systemi.cpp:5396, then perform the memcpy, then retrieve the debugLogFilename if the pointer had been set.

basically, replace (around fmod_systemi.cpp:5396):

[code:2h8b8qls]
memcpy(settings, &mAdvancedSettings, usercbsize);

settings->cbsize = usercbsize;
settings->ASIOSpeakerList = speakerlist;

ifdef FMOD_DEBUG

if (settings->debugLogFilename)
{
    FMOD_strcpy(settings->debugLogFilename, FMOD::gGlobal->gDebugFilename);
}

endif

[/code:2h8b8qls]
with

[code:2h8b8qls]
char* debugLogFilename = settings->debugLogFilename;

memcpy(settings, &mAdvancedSettings, usercbsize);

settings->cbsize = usercbsize;
settings->ASIOSpeakerList = speakerlist;
settings->debugLogFilename = debugLogFilename

ifdef FMOD_DEBUG

if (settings->debugLogFilename)
{
    FMOD_strcpy(settings->debugLogFilename, FMOD::gGlobal->gDebugFilename);
}

endif

[/code:2h8b8qls]

  • You must to post comments
0
0

Thanks i’ve updated this for the next release.

  • You must to post comments
Showing 3 results
Your Answer

Please first to submit.