Heap corruption: What could the cause be?

Question

Hi,

I am investigating a crash due to heap corruption. As this issue is non-trivial and involves analyzing the stack and dump results, I have decided to do a code review of files related to the crash.

To be frank, I don't have in-depth knowledge of when the heap could be corrupted.

I would appreciate if you could suggest scenarios which could lead to heap corruption.

Platform: Windows XP

Language: C++

Compiler: VC6

Thanks in advance

SSS

Answer 1

Welcome to hell. There is no easy solution so I will only provide some pointers.

Try to reproduce the bug in a debug environement. Debuggers can pad your heap allocations with bound checks and will tell you if you wrote in those bound checks. Also, it will consistently allocate memory using the same virtual addresses, making reproductibility easier.

In that case, you can try an analyser tool such as Purify. They will detect pretty much anything nasty that your code is doing but will also run VERY slowly. Such a tool will detect out of bound memory access, freed memory access, trying to free twice the same block, using the wrong allocator/deallocators, etc... Those are all kind of conditions that can stay latent for very long and only crash at the most inopportune moment.

Answer 2

Common scenarios include:

• Writing outside the allocated space of an array (char *stuff = new char[10]; stuff[10] = 3;)
• Casting to the wrong type
• Uninitialized pointers
• Typo error for -> and .
• Typo error when using * and & (or multiple of either)

[EDIT] From the comments, a few more:

• Mixing new [] and new with delete [] and delete
• Missing or incorrect copy-constructors
• Pointer pointing to garbage
• Calling delete multiple times on the same data
• Polymorphic baseclasses without virtual destructors

Answer 3

You can look at the sample chapter from the Advanced Windows Debugging book which provides various examples of heap corruption.

EDIT: If you are using stl containers which might move elements during changes (i.e. vector, deque), ensure that you are not keeping references into such elements across operations which might changes it.

Answer 4

Its a common mistake to free() or delete allocated memory more than one. It may help to insert something like *var = NULL after such calls, and to check for != NULL when calling free. Although in C++ its legal to call delete with a NULL variable, calling C - free() will fail.

Also a common problem is to confuse delete and delete [].

Variables allocated with new must be released with delete.

Array allocated with new [] must be released with delete[].

Also make sure not to mix C- style memory management (malloc, calloc, free) with C++ style memory management (new/delete). In legacy code often both are mixed, but things allocated with the one can not be freed with the other.

All of these errors will usually not be recognized by a compiler.

Answer 5

There are products that will observe the memory allocations and deallocations, and produce a report on anomalies. Last I used one, they weren't cheap, but I don't know what the situation is right now. However, finding stuff for VC++ 6 might be a problem.

Remember that you're liable to be getting heap corruption a lot more often than you're going to crash, so be attentive to the problem reports, and fix all heap corruption.

I'd suggest using std::tr1::smart_ptr<> instead of raw pointers everywhere, but I'm not sure VC++ 6 is going to support that.

Why are you still on VC++ 6? Would it be practical to upgrade? The tools are better with the more recent versions, and they fully support smart pointers.

Answer 6

Check out the answers to this related question.

The answer I suggested provides a technique which may be able to get you back to the code that is actually causing the heap corruption. My answer describes the technique using gdb but I'm sure you must be able to do something similar on windows.

The principle at least should be the same.

Answer 7

During freeing heap memory, first child memory block need to be deleted and then parant memory block otherwise the child momory block would be leaked parmanently which causes the crash after running the tool millions of times.. ex:

constQ= new double* [num_equations];
for(int i=0;i<num_equations;i++)
{
constQ[i]=new double[num_equations];
for(int j=0;j<num_equations;j++)
{
constQ[i][j]=0.0;
}
.
.
.

//Deleting/Freeing memory block 
//Here the below only parent memory block is deleted, the child memory block is leaked.

if(constQ!=NULL)
{
delete[] constQ;
constQ=NULL
} 
//Correct way of deleting heap memory..First delet child block memory and then Parent block

if(constQ!=NULL)
{
for(int i=0; i <num_equations;i++)
{
delete[] constQ[i];
delete[] constQ;
constQ=NULL
}

Answer 8

If you have access to a *nix machine, you can use Valgrind.

Answer 9

Every time you do something which isn't defined in the language standard, it is undefined behavior, and one of the ways in which it might manifest itself is through heap corruption. There are about three million ways to do this in C++, so it's really impossible to say.

A few common cases are double-freeing dynamically allocated memory, or writing outside the bounds of an array. Or writing to an uninitialized pointer.

Recent versions of Microsoft's compiler add an /analyze compiler switch which performs a bunch of static analysis to catch such errors. On Linux, valgrind is an obvious choice.

Of course, you are using VC6 which has been unsupported for years, and which has a number of known bugs, resulting in invalid code being generated.

If possible, you should upgrade to a proper compiler.

Answer 10

An additional debugging tip is to look at the values that are being written to the wrong place using the raw memory view. Is it writing zeros... strings... some other recognizable number pattern? If you can see the corrupted memory at some point after the error occurs, that can provide a hint of the code that caused it.

Also always set pointers to null after deleting them even in destructors. Sometimes unexpected things can be triggered during a destructor chain in a base class than cause an access to a partially deleted sub-class.

Answer 11

The most difficult memory corruption bug I've run into involved calling a function in a DLL that returned a std::vector and then letting that std::vector fall out of scope: which is basically the whole point of std::vector. Unfortunately it turned out that the DLL was linked to one version of the C++ runtime, and the program was linked to another; which meant that the library was calling one version of new[] and I was calling a completely different version of delete[] (looking for the memory in completely different memory arenas to boot).

That is not what's happening here, because that failed every time and according to one of your comments "the bug manifests itself by a crash one in a millionth time." I would guess that there's an if statement that gets taken once in a million times and it causes a double delete bug.

I recently used evaluation versions of two products that may help you: IBM's Rational Purify and Intel Parallel Inspector. I'm sure there are others (Insure++ is mentioned a lot). On Linux you would use Valgrind.