READ_DANGLING in C++ destructor

LegacyForumLegacyForum Posts: 1,664 ✭✭
edited December 2016 in Insure++
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?


  • LegacyForumLegacyForum Posts: 1,664 ✭✭
    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.
  • LegacyForumLegacyForum Posts: 1,664 ✭✭
    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.
  • LegacyForumLegacyForum Posts: 1,664 ✭✭
    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.
  • LegacyForumLegacyForum Posts: 1,664 ✭✭

    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 {
     Foo(char *p) : _ptr(p) { }
     ~Foo() {if (*_ptr) delete[] _ptr; } // if _ptr is already destroyed, this will produce READ_DANGLING followed by FREE_DANGLING

    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()
       return 0;

Sign In or Register to comment.