Debugging Memory crashes

Programs store data in any of the following ways:

Global	All variables of objects declared as global in a C/C++ program fall into this category. This also includes static variable declarations.
Heap	Memory allocated using new or malloc is allocated on the heap. In many systems, stack and heap are allocated from opposite sides of a memory block. (See the figure below)
Stack	All local variables and function parameters are passed on the stack. Stack is also used for storing the return address of the calling functions. Stack also keeps the register contents and return address when an interrupt service routine is called.

Global Memory Corruption

If a global data location is found to be corrupted, there is good chance that this is caused by array index overflow from the previous global data declarations. Also the corruption might have been caused by an array index underflow (array accessed with a negative index) from the next variable declarations. The following rules should be helpful in debugging this condition:

• If you have a debugging system which allows you to put breakpoints on data write to a certain location, use that feature to find the offending program corrupting the memory. If you don't have the luxury of such a tool, the following steps might help.
• If the variable is a part of structure, check if overflow/underflow of previous or next variables in the structure could have caused this corruption.
• Sometimes looking at the corrupted memory locations can also give a good idea of the cause of corruption. You might be able to recognize a string or data pattern identifying the culprit. This might be your only hope if the corruption is caused by an un-initialized pointer.

 Heap Memory Corruption

Corruption on the heap can be very hard to detect. A heap corruption could lead to a crash in heap management primitives that are invoked by memory management functions like malloc and free.

• If a crash is observed in memory management primitives of the operating system, heap corruption is a possibility. It has been observed that memory buffer corruption sometimes leads to corruption of OS buffer linked list, causing crashes on OS code.
• If a memory corruption is observed in an allocated buffer, check the buffers in the vicinity of this buffer to look for source of corruption.
• Corruption of buffers close to heap boundary might be due to stack overflow or stack overwrite leading to heap corruption
• Conversely, stack corruption might take place if a write into the heap overflows and corrupts the stack area.
•  

  Stack Memory Corruption

  
  Programming languages use the stack for a large number of operations like maintaining local variables, function parameter passing, function return address management.
   Here are the rules for debugging stack corruption:
• If a crash is observed when a function returns, this might be due to stack corruption. The return address on the stack might have been corrupted by stack operations of called functions.
• Crash after an interrupt service routine returns might also be caused by stack corruption.
• Stack corruption can also be suspected when a passed parameter seems to have a value different from the one passed by the calling function. 
• When a stack corruption is detected, one should look at the local variables in the called and calling functions to look for possible sources of memory corruption. Check array and pointer declarations for sources of errors.
• Sometimes stray corruption of a processors registers might also be due to a stack corruption. If a register gets corrupted due to no reason, one possibility is that an offending thread or program corrupted the register context on the stack. When the register is restored as a part of a context switch, the task crashes.
• Corruption in heap can trickle down to the stack.
• Stack overflow takes place when a programs function nesting exceeds the stack allocated to the program. This can cause a stack area or heap area corruption.