CODEWITHSUNDEEP
c++debuggingvisual-c++corruptionheap-memory
user470760
user470760

Reputation:

C++ Heap Corruption

I haven't done any C++ in a while, but decided to finish a big project I was working on for someone. I am getting the following error message now though...

HEAP CORRUPTION DETECTED: after Normal Block (#1761) at 0x17DEB940. CRT Detected that the application wrote to memory after end of heap buffer.

I have been stepping through all of the functions I thought might have caused it but I am at a loss. Is there any way using the more advanced debugging features to hunt this down?

Upvotes: 8

Views: 9973

Answers (4)

floyd73
floyd73

Reputation: 1240

Try using AppVerifier with normal pageheap enabled. If you then attach a debugger to the process and have a heap corruption with some luck it will break at the point where the memory block gets corrupted (by a block write overrun or underrun). With a little effort you can also get a callstack of the code that allocated every heap block, something that can also help to track down the error.

Tracking these errors can be tricky though, for detailed information check the Advanced Windows Debugging book which has a whole chapter devoted to the subject.

Upvotes: 1

david
david

Reputation: 92

It does sound like a classic memory corruption error. The platform would be helpful information. Without seeing your code and it's complexity there are a couple of possibilities:

  1. I'll make a guess that the runtime library would allow you to add calls to the heap validation code directly from your code. I would suggest placing calls to the heap validation code in various places in your code so you can figure out where things go wrong. You'll find the place where the heap goes bad and you'll know that it was ok at the previous call. Keep narrowing down that window if you need to and then review the code where the problem occurs.

  2. If the same steps corrupt exactly the same place in memory, you should be able to use your debugger to set a breakpoint (or watchpoint) on the memory getting changed. Some of those changes may be intended, but you should be able to figure out which one is the culprit.

You might use a combination of the two if your code is particularly complex or the steps needed to reproduce this are long - narrow down a section of code that it problematic and then place a breakpoint on the memory location that gets corrupted.

david

Upvotes: 4

Bill Lynch
Bill Lynch

Reputation: 82006

On Linux I would recommend valgrind as a tool that would tell you exactly what went wrong. You may look into some Windows alternatives for it here.

Upvotes: 2

Helge Becker
Helge Becker

Reputation: 3253

Try to catch it with Intruments.

Sounds a bit like a classical C error. You are sure you don't write beyond an c array ( like int[xyz]) in a while or for loop? It don't cause any errors, but you get strange effects in a lot spaces that have nothing to do with the part where the bug lives. :p

Upvotes: 1

Related Questions