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.
