0
0

Hi everyone,

I’m stuck with a weird problem that seems to be related to FMOD::EventCategory::setUserData.

I’ve written a wrapper class around FMOD::EventCategory that encapsulates all its methods and hierachy. This class holds a pointer to an EventCategory. My initializaton code looks like this (checking code omitted for clarity, but everyting is "FMOD_OK"):

[code:3oc81d6j]// Constructor
CSoundEventCategory::CSoundEventCategory( )
: m_pCategory(NULL)
{
}

// Initializaton method. pCategory is a valid FMOD::EventCategory* retrieved in my audio manager class using
// ...
// m_pEventSystem->getCategoryByIndex(i, &pCategory);
// pNewSoundEventCategory->Init(pCategory);
// ...
//
void CSoundEventCategory::Init( FMOD::EventCategory* pCategory )
{
m_pCategory = pCategory;
m_pCategory->setUserData(this);
// ... Do stuff
}[/code:3oc81d6j]

CSoundEventCategory inherits from ISoundEventCategory, a pure virtual class with no member functions. Therefore, the first member of this class will be the vtable and then my FMOD::EventCategory pointer, as the debugger confirms.

Everything seems fine, but when shutting down the application, exceptions such as
"Unhandled exception at 0x085fc03b in My_App.exe: 0xC0000005: Access violation writing location 0x4b5db088."
or similar arise when calling my wrapper class methods.
A little debugging has revealed the possible source of my problems. In the previously mentioned initialization function (using the memory inspector), a weird thing shows up (some numbers are provided to ilustrate the problem):

[code:3oc81d6j]void CSoundEventCategory::Init( FMOD::EventCategory* pCategory ) // this = 0x059520C8
{
m_pCategory = pCategory;

// <---- Here the first bytes from 0x059520C8 on are: 6c 2b fa 01 c0 bd 5f 08 00 00 00 00 cd cd
m_pCategory->setUserData(this);
// <---- Here the first bytes are: 48 be 5f 08 c0 bd 5f 08 00 00 00 00 cd cd 
// See how the fist four bytes changed, the rest remains the same. 
//...

}[/code:3oc81d6j]

I presume this leads to bad indirections (and, thus, to disaster), since vtable has been overwritten.

If I do:
[code:3oc81d6j]
pCategory->setUserData((void*)0x01) // Let’s Hack!
[/code:3oc81d6j]

"Access violation writing location 0x00000001" Shows up.

I also have a wrapper class around FMOD::EventGroup which does almost the same (m_pCategory->setUserData(this)) but not a single byte is changed in my class, but in the memory pointed by FMOD::EventGroup* (as expected).

Is there any chance that FMOD::EventCategory::setUserData is somehow bugged? Or is it just that I’m missing/misinterpreting what setUserData is meant for?

I’m using fmod api 4.28.02.

Any help or pointer will be appreciated.

Thanks in advance,
Juan F. Nogueras

  • You must to post comments
0
0

Hi Janko, welcome to the forums.

I have tried reproducing the behaviour you’re seeing but to no avail. Internally setUserData looks like this:
[code:17grmauw] m_userdata = userdata;
return FMOD_OK;[/code:17grmauw]

There is nothing I can think of which would cause this to stomp on the memory of your wrapper class’ vtable pointer. One possibility is the compilers temporary files are stale and causing the compiler to do weird things. If you haven’t already could you try cleaning the solution and doing a complete rebuild?

-Pete

  • You must to post comments
0
0

Hi Peter,

Thanks for the welcome and for the quick response.

I’ve tried the clean & rebuild suggestion but with no luck.

It’s good to know, though, that I was using setUserData correctly and the implementation does just fine what it is supposed to do. This looks like a problem on my side, so I’ll keep on investigating.
If anything comes to mind, please let me know.

Thanks again.
Juan.

  • You must to post comments
0
0

Hi janko,

I could possibly be binary incompatibility. Are you 100% sure that the FMOD header, lib and dll are all the same version? Maybe something strange is happening in there.

-Pete

  • You must to post comments
0
0

Hi Peter,

Yes! That was it. I was using an old version of the header files. My project’s include directories was pointing to an old one due to a svn conflict I didn’t resolve correctly. My mistake.

And this not only solved this really weird thing, but also a crash when trying to call MusicSystem::loadSoundData.

Thanks a lot for pointing me in the right direction. You saved me a lot of brain-ache 😛

Juan.

  • You must to post comments
0
0

Glad to be of assistance.

  • You must to post comments
Showing 5 results
Your Answer

Please first to submit.