Editing Dangling pointer (section)

==Dangling pointer detection==

To expose dangling pointer errors, one common programming technique is to set pointers to the [[null pointer]] or to an invalid address once the storage they point to has been released. When the null pointer is dereferenced (in most languages) the program will immediately terminate—there is no potential for data corruption or unpredictable behavior. This makes the underlying programming mistake easier to find and resolve.  This technique does not help when there are multiple copies of the pointer.

Some debuggers will automatically overwrite and destroy data that has been freed, usually with a specific pattern, such as <code>[[0xDEADBEEF]]</code> (Microsoft's Visual C/C++ debugger, for example, uses <code>0xCC</code>, <code>0xCD</code> or <code>0xDD</code> depending on what has been freed<ref>[http://msdn2.microsoft.com/en-us/library/aa270812(VS.60).aspx Visual C++ 6.0 memory-fill patterns]</ref>). This usually prevents the data from being reused by making it useless and also very prominent (the pattern serves to show the programmer that the memory has already been freed).

Tools such as [[Polyspace]], [[Rogue Wave Software|TotalView]], [[Valgrind]], Mudflap,<ref>[https://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging Mudflap Pointer Debugging]</ref> [[AddressSanitizer]], or tools based on [[LLVM]]<ref>Dhurjati, D. and Adve, V. [http://llvm.org/pubs/2006-DSN-DanglingPointers.pdf Efficiently Detecting All Dangling Pointer Uses in Production Servers]</ref> can also be used to detect uses of dangling pointers.

Other tools ([http://www.cis.upenn.edu/acg/softbound/ SoftBound], [[Insure++]], and [http://www.semanticdesigns.com/Products/MemorySafety CheckPointer]) instrument the source code to collect and track legitimate values for pointers ("metadata") and check each pointer access against the metadata for validity.

Another strategy, when suspecting a small set of classes, is to temporarily make all their member functions [[Virtual method|virtual]]: after the class instance has been destructed/freed, its pointer to the [[Virtual method table|Virtual Method Table]] is set to <code>NULL</code>, and any call to a member function will crash the program and it will show the guilty code in the debugger.