READ_DANGLING in C++ destructor

LegacyForum

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?

LegacyForum

No it should see the memory actually free'd and if then that memory was read then you would get a READ_DANGLING error reported.

LegacyForum

That's what I would expect, and that is why I am confused about READ_DANGLING referring to "this" inside of a destructor since "this" should be valid until the end of the destructor.

LegacyForum

Can you post the actual message and a snippet of the code that's representative of what it's reporting this on. Also what version of insure you're using and what compiler version.

LegacyForum

Hi,

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:

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