Problem with list.

Problem with list.

[Aseem Rastogi]

Hi,

Can somebody explain the following behaviour? Even after deleting the 
member of list, I am not getting segmentation fault at last line (as 
expected). Rather foo () output is what comes out.


#include<list>

list<A*> l;

int main ()
{
    A* a = new A ();

    cout << a->foo () << endl;        // Prints 0 which is OK

    l.push_back (a);

    for (list<A*>::iterator it = l.begin (); it != l.end (); it++) {
        delete (*it);
    }

    cout << a->foo () << endl;       // Should give Segmentation Fault 
but its not !!!! Prints 0 which is not OK.
}

Regards,
Aseem.

-- 
The end is always good. If it's not good, it's not the end.

Re: Problem with list.

[John Love-Jensen]

Hi Aseem,

> Can somebody explain the following behaviour?

After you relinquish a pointer to l list, you continue to hold onto the
pointer in a.

When the A object in l list is deleted, the a pointer is left with a
dangling reference.

A dangling reference is not guaranteed to cause a segmentation fault when
dereferenced.  It appears that the heap still had the "ghost" of the A
object, which the a pointer accessed -- but it could have also caused a seg
fault.  The behavior is undefined.

There are several strategies you can employ to help you catch programming
mistakes like this.

One is to use a heap manager that scrubs all released memory to some garbage
value.  0xDEADBEEF is a common choice, since it is conspicuous in a
debugger.  You probably wouldn't want that overhead in production code, but
for diagnostic purposes it can be quite handy.

Another strategy is to use managed pointers, such as std::auto_ptr or one of
the various managed pointed in Boost, which will explicitly relinquish
ownership.

Another strategy is to use a third party product to help detect this kind of
situation.  Such as Electric Fence, ValGrind, IBM Rational Purify &
Quantify, or Nu-Mega Technologies Bounds Checker... just to name a few.
There are a lot out there.

q.v. http://www.sdmagazine.com/jolts/prev_utl.htm

HTH,
--Eljay

Re: Problem with list.

[Aseem Rastogi]

Thanks for your reply ElJay.

What puzzled me is that if I do

A* b = a;

delete b;

a->foo ();       //This gave me a segmentation fault.

Your explaination helps. But, can I be sure that the memory assigned to 
'a' in first place from heap has been freed and if required by some 
other application it will be available with kernel?

Thanks,

Regards,
Aseem.

John Love-Jensen wrote:

>Hi Aseem,
>
>>Can somebody explain the following behaviour?
>>
>
>After you relinquish a pointer to l list, you continue to hold onto the
>pointer in a.
>
>When the A object in l list is deleted, the a pointer is left with a
>dangling reference.
>
>A dangling reference is not guaranteed to cause a segmentation fault when
>dereferenced.  It appears that the heap still had the "ghost" of the A
>object, which the a pointer accessed -- but it could have also caused a seg
>fault.  The behavior is undefined.
>
>There are several strategies you can employ to help you catch programming
>mistakes like this.
>
>One is to use a heap manager that scrubs all released memory to some garbage
>value.  0xDEADBEEF is a common choice, since it is conspicuous in a
>debugger.  You probably wouldn't want that overhead in production code, but
>for diagnostic purposes it can be quite handy.
>
>Another strategy is to use managed pointers, such as std::auto_ptr or one of
>the various managed pointed in Boost, which will explicitly relinquish
>ownership.
>
>Another strategy is to use a third party product to help detect this kind of
>situation.  Such as Electric Fence, ValGrind, IBM Rational Purify &
>Quantify, or Nu-Mega Technologies Bounds Checker... just to name a few.
>There are a lot out there.
>
>q.v. http://www.sdmagazine.com/jolts/prev_utl.htm
>
>HTH,
>--Eljay
>
>


-- 
The end is always good. If it's not good, it's not the end.

Re: Problem with list.

[John Love-Jensen]

Hi Aseem,

>But, can I be sure that the memory assigned to 'a' in first place from heap has
been freed and if required by some other application it will be available with
kernel?

Using one of the strategies I described, yes, you can be sure.

Note:  one of the heap managers I wrote for my own diagnostic purposes NEVER
actually frees memory.  Memory just grows and grows and grows, until
eventually all memory is exhausted.  Not useful for a production
application, but sometimes useful for diagnostics and debugging certain
problems (via unit tests).

Sincerely,
--Eljay