__vftptr is NULL

Question

We received crash dump from customer site. I see that in one of the structures o nstack __vfptr is NUL.

Does it always point to problematic condition (memeory overrun, deleting object twice...) or is there case where this pointer can be null.

Answer 1

While generally the answer is "yes", i think you should consider that might be a debugger glitch too.

Answer 2

Are you using memset() anywhere on instances of your classes?

I've seen this problem before and the cause was code like

class C : SomeClassWithVirtualFunctions
{
public:
  C()
  {
    memset( this, 0, sizeof ( C ) ) ; // BAD!! sets _vfptr to 0 too
  }
}

cppcheck is neat

Answer 3

Normally, I get vptr corruption when the object has been deleted twice (and yes, it is always a bug). Most of the time for me, the vptr is just pointing to some random block of memory, but it sounds like yours is getting overwritten by NULL, which could be the OS blanking out reclaimed memory, or it could be a pointer to what is doing the overwriting.

Consider using boost::shared_ptr to maintain lifetime with ownership.

Answer 4

This can happen if you try to obtain run-time type information (i.e. use the typeid function) on an object of a class that has no virtual functions.

Answer 5

You may be seeing a partially destroyed object on the stack. The compiler may mark part of an object as destroyed by clearing the virtual function table pointer, so that it can correctly implement destructors of classes with "diamond" inheritance (multiple inheritance of classes that have a common, virtual base class) If the program crashes during the destruction of the object, you'll see the partially destroyed object in the dump.

Older MSVC compilers did not correctly implement destructors for classes with diamond inheritance. Any time you tried to destroy one, the program would crash. I'm not sure if this is still the case.