How to debug/fix an access violation (Heap Corruption)

Question

My app crashes (repeatably) after I have moved from VS2005 to VS2008 (win32).

If I step in the debugger, I get:

Access violation reading location 0x00000014

Firstly, I see that the class object at the crash line, has a NULL _vptr. But some other objects of the same class have non-NULL _vprt:)

Secondly, if I change the order of the member object declarations, the crash moves to some other line.

So I guess this must be a corrupt heap problem.

Do you agree? if yes, could the number of allocations in the stack such as "char buffer[8192]" be a problem?

I have tried purify, application verifier without luck. My app is a plugin (dll) living in a proprietary application. I can only attach with a debugger.

Thanks in advance,

Paul

Answer 1

Do you agree? if yes, could the number of allocations in the stack such as char buffer[8192] be a problem?

Yes, Heap corruption can be caused by an array of huge sizes allocated on Heap(by using new or malloc). If you are creating an huge sized array on Stack, If the adjacent memory is allocated to another object, the program will overwrite that object's data, resulting in crashes. So both might be hazardous but due to different problems. If you are talking about an stack array, No it cannot cause heap corruption simply because stack or heap(rather free store in C++) are two different memory entities.

Heap corruptions can be very frustrating and difficult to diagnose. And there are not definite steps to solve such a problem though there are number of methods which one can try to debug such errors.

Debugging Heap Corruption in Visual C++ Using Microsoft Debugging Tools for Windows is an excellent source which documents techniques specific to visual c++

Answer 2

This definitively looks like a heap corruption - at some point, your code write zeros on the top of the object, and that kills the vptr. The reason it happens after moving from VS2005 to VS2008 is probably because the heap layout has somewhat changed. The bug was probably in VS2005 as well, but its damage was unnoticed.

Using the tools you mention usually solves such problems. What kind of no luck have you had when using them?

Since you say your app repeatedly crashes in the same way, you can add checks in your code. Continuously verify the damaged object (make sure its beginning wasn't zeroed), and break when you observe a damage. Looking at the activity between the latest successful validation and the break would help you focus. Just have in mind that any change in heap usage might hide the problem, namely corrupt some other location.

Answer 3

This turned out to be an issue related to preprocessor defines being different between my app and some of its dependencies (libs).