Thread: How to find memory corruption?

A few methods I've used:

Identify the culprit by looking at the data: Try to analyze what the content of the memory is - does it contain pointers, if so, what are those pointers pointing to? Does it contain some known data of some other type (text strings, floating point numbers, etc).

Build your own "overstepping the line" detection: Modify the malloc/free or new/delete to "overallocate" by some amount and fill with a pattern, and keep a list of known allocations. Every so often (e.g. every N allocations/frees), scan the list to see that your "overstep clay" is intact. If you store who allocated the memory (file and line), then you can usually figure out who the culprit is from that. "keeping" a list of "deleted memory", which is filled with a pattern to identify usage of freed memory is also a good idea. You can make that a circular buffer/FIFO, so you keep the last 256 or something allocations, and remove the oldest when the list is full.

Add extra checking for out of bounds: Guess [perhaps using one of the two methods above] where the fault is and add code to check for out of bounds access to memory. Add NULL-pointer assignment whenever something is deleted that doesn't also go out of scope immediately.

Code review: Again, this method works best if you already have a good idea of where in the code it goes wrong. Have a friend/colleague sit next to you, whilst you explain what the code does. Explaining to someone else forces you to look more at the code, so it usually goes something like this: "And here I do this, and then we check that X is greater than Y - Ah, hang on a bit - we should check that X is greater than or EQUAL to Y."

--
Mats

Originally Posted by matsp

Build your own "overstepping the line" detection: Modify the malloc/free or new/delete to "overallocate" by some amount and fill with a pattern, and keep a list of known allocations. Every so often (e.g. every N allocations/frees), scan the list to see that your "overstep clay" is intact. If you store who allocated the memory (file and line), then you can usually figure out who the culprit is from that. "keeping" a list of "deleted memory", which is filled with a pattern to identify usage of freed memory is also a good idea. You can make that a circular buffer/FIFO, so you keep the last 256 or something allocations, and remove the oldest when the list is full.

Add extra checking for out of bounds: Guess [perhaps using one of the two methods above] where the fault is and add code to check for out of bounds access to memory. Add NULL-pointer assignment whenever something is deleted that doesn't also go out of scope immediately.

This is usually already done by Visual C++ / Visual Studio, so you can save time and energy by using its debugger for that.
Another very useful method I find is data breakpoints (VC supports 'em). Basically, you can set breakpoints so the debugger breaks when a certain memory location is changed or written to.

Say, for example, you get an access violation. The pointer is not NULL. That means it's either free or pointing somewhere it shouldn't.
Then identify the variable. If it's local, then it's probably a bug in the function. Just use stepping and see if it isn't a bigger problem.
If it's isn't local, or if the local variable gets some value from some other non-local variable (if it's a linked list or such), then use a data breakpoint.
You can try to have the debugger break when it writes the current value of the pointer to the pointer. If you replicate the exact situation, it might just work.
Otherwise you may have to track down everytime it changes. You can also add to allow it to break after the pointer has been modified X times. It's useful when you know a little more about the time frame when the bug occurs, so you don't have to break for every harmless change.

Then it's just stepping and debugging and figuring out what went wrong.
This is a typical approach for me and very successful, I might add.