READ_DANGLING in C++ destructor
I have seen that several times I will receive a READ_DANGLING inside of a destructor while accessing class member variables. Is Insure++ marking the memory as deallocated as soon as it hits operator delete() but prior to the actual destructor call?
Tagged:
0
Comments
I should also mention a few things:
1/ You can get a READ_DANGLING in a destructor if you attempt to destroy the same object twice.
2/ It's possible that certain combinations of overloaded operator delete() could confuse the runtime.
3/ In slightly older versions of Insure++ the READ_DANGLING message can be *slightly* misleading, in that it refers to the "this" object, instead of the *member* which may have already been destroyed.
Consider this code:
class Foo {
public:
Foo(char *p) : _ptr(p) { }
~Foo() {if (*_ptr) delete[] _ptr; } // if _ptr is already destroyed, this will produce READ_DANGLING followed by FREE_DANGLING
private:
};
void func()
{
char *p = new char[42];
p[0] = 'a';
Foo f(p);
delete[] p; // the memory block pointed to by p is now destroyed.
return; // the block will be read in Foo::~Foo() and *also* re-deleted.
}
int main()
{
func();
return 0;
}
--Rich