Debug Assertion Failed: _BLOCK_TYPE_IS_VALID

Hey all, trying to get a project working for a class, and I'm running into an odd error. We're using unit testing and my tests appear to be working fine right up until the very end, where they pop up a nice error window for me:

Debug Assertion Failed!
Program: (my executable)
File: f:\dd\vctools\crt_bld\self_x86\crt\src\dbgdel.cpp
Line: 52
Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

What's really weird is that I used the debugger to step through the code line-by-line, and this doesn't happen during the test, it happens during the automated garbage collection at the end. When the test method is done, it calls the destructor for my class; that runs fine right up until it tries to leave the destructor, which is when this error goes off. All the actual clean-up inside the destructor works fine.

I looked around on Google about this error but all I could really find was some suggestions that it had to do with using a bad pointer, and I know that's not the problem, since I'm obviously not using a pointer in a line that's just a close curly bracket to end the destructor.

Anyone know anything about this one? I'd be happy to post code, but there's a lot of it, and I don't wanna just textwall people without some idea which parts it would be helpful to look over.
OK, got it fixed. Apparently when a derived class goes out of scope, in addition to its own destructor getting called, the super-class' destructor gets called. Adding something to the super-class' destructor to make sure it checked that its pointer hadn't already been deleted before deleting appears to have fixed the problem.

I thought inheritance wasn't supposed to automatically call the super-class' constructors & destructors?
Last edited on
Base class constructor is always called before the derived constructor; base class destructor is always called after derived destructor.

Something sounds awfully suspicious with the statement "Adding something to the super-class' destructor to make sure it checked that its pointer hadn't already been deleted before deleting appears to have fixed the problem."
I just had the derived destructor set the pointer to zero after deleting it, and had the base class destructor only delete the pointer if it wasn't equal to zero.

Like I said, I didn't think that C++ automatically called the base class' constructor & destructor. Maybe I was thinking about the stuff you have to do to get it to call a constructor of the base class that actually takes arguments; I guess I figured it didn't call it all, when apparently it just calls the default constructor.
I just had the derived destructor set the pointer to zero after deleting it, and had the base class destructor only delete the pointer if it wasn't equal to zero.


You have a design flaw.

Only one of these classes should be the owner of this pointer. Both classes should not be trying to delete it.

Who owns this pointer? If the base class can see it, I'm assuming the base class is the owner -- so the derived class probably shouldn't be doing anything with this pointer.
Topic archived. No new replies allowed.