I am debugging a defect and have narrowed it down to the vtable pointer for an object being 0xdddddddd
. This answer indicates that Win32 debug builds will generally set dead memory, or memory which has been deleted, to this special value.
Note that the pointer itself looks valid, it's just the vtable pointer that is 0xdddddddd
.
Here's a snippet of code:
std::list<IMyObject*>::const_iterator it;
for (it = myObjects.begin(); it != myObjects.end(); ++it)
{
IMyObject* pMyObject = *it;
if (pMyObject == 0)
continue;
pMyObject->someMethod(); // Access violation
}
If I break at the line of the access violation and watch pMyObject
, I can see that pMyObject
itself has a valid address (0x08ede388
) but the __vfptr
member is invalid (0xdddddddd
).
Some notes:
Any suggestions about how to debug this further?
Okay wow, so I've been programming in c++ for years and never discovered this until now... There are actually magic numbers/magic debug values that you can lookup to see what's going on with your raw pointers while debugging!
See here: In Visual Studio C++, what are the memory allocation representations?
and here: https://en.wikipedia.org/wiki/Magic_number_(programming)#Magic_debug_values
You are using the pointer after it has been released. Get a stack trace from a breakpoint in the destructor to see what is deleting it. Or better yet, use shared_ptr<> to avoid the problem.
If you start the program, put a break point at where you create the object. Then add a memory break point. This will fire if you overwrite or delete the memory. Well, or change it in any way.
Your object will look correct if the memory isn't overwritten, but your vtable may not be depending on compiler specifics.
It could also be a size problem if you are using inheritance. If you are using any kind of bucket memory or storing objects by anything but the pointer.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With