Debugging a heap corruption

[Stewbond]

I'm in some trouble and I've never debugged issues like this before.

My project compiles, but during initialization (which uses a LOT of dynamic memory allocation), I'm getting this error:

Unhandled exception at 0x5d0c797f (msvcp90d.dll) in MyExe.exe: 0xC0000005: Access violation writing location 0xcdcdcdcd.

When looking through the call stack the first line of a constructor (after initialization list). It's comming from the .push_back() part of the line, so I assume the new TExtValue() has been created properly. m_Values is a vector of TValue* which is an abstract class that TExtValue extends.
m_Values.push_back(new TExtValue("SomeName", "-", fromHost.Value1));

Edit:
When looking through the debugger, it seems that 0xcdcdcdcd is an address assigned to pointers which are uninitialized. Does that sound like a likely cause?

[MikeyBoy]

When looking through the debugger, it seems that 0xcdcdcdcd is an address assigned to pointers which are uninitialized. Does that sound like a likely cause?

Yes, that sounds like the most likely cause.

[helios]

I assume the new TExtValue() has been created properly

Why? Just rerun and see exactly which function is crashing.

Crashes on allocations are usually a sign that fun times are approaching. These kinds of bugs can be caused by such things as:
* Buffer overflows.
* Double deletions.
* Misuses of free()/delete.
* switching on uninitialized variables, depending on compiler smartness.
If any of these happen at any point in execution, the program can crash (or not) at any point later on, usually when de/allocating memory or doing I/O.
If your project is portable, you'll save yourself many headaches by compiling for Linux and running through Valgrind. If not, you can try one of the memory debuggers available for Windows; I've never seriously used them, so I can't recommend any, though.

[Stewbond]

Thanks for the responses.

The crash occurs in vector<TValue*>::push_back();. This is where I'm starting to get confused.

http://imgur.com/2JI76jM

This image is a snapshot of the image I'm trying to push_back. It has a size and a valid address.

My other issue is that the class I am creating is defined in a static library that I don't have visibility of, so I don't have the freedom to change that class. I know this should work, because another (closed source) application that I am running links to the ame libraries and it is very stable.

[coder777]

the temp object looks corrupt/invalid. The problem certainly is not the push_back() function. Go up the call stack until your own code and until you have just valid data (no cdcdcd...). Then you have a starting point for your debug/output

[JLBorges]

See http://msdn.microsoft.com/en-us/library/zh712wwf(v=vs.110).aspx
http://msdn.microsoft.com/en-us/library/vstudio/974tc9t1(v=vs.110).aspx

[kbw]

I haven't used Windows for a few years, but isn't 0xcdcdcdcd written by the debug heap on free?

It the crash repeatable, in that it crashes in exactly with same way with the same addresses when rerun? If so, you can watch that memory and step thru the app.

If not, you could verify that 0xcdcdcdcd is written on free in the debug heap and look for your dangling reference. For example, are you mssing a copy constructor/assingment operator somewhere important?

It sounds basic, but often you have to go back to basics to sort out these problems.

[coder777]

See the 'magic debug values':

http://en.wikipedia.org/wiki/Magic_number_%28programming%29#Magic_debug_values

[Disch]

Seeing 0xcdcdcdcd makes me think this problem is less about heap corruption and more about you trying to dereference a bad pointer.

When looking through the call stack the first line of a constructor (after initialization list). It's comming from the .push_back() part of the line

So... you mean the push_back call is inside your constructor? Or the constructor is being called from push_back?

In any event... the debugger should be snapping on the exact line where the bad memory access is occurring. It's unlikely this is happening inside push_back, so you might not have to go down on the call stack at all to see where the problem is.


m_Values.push_back(new TExtValue("SomeName", "-", fromHost.Value1));

I'm skeptical that this call is really the source of your problem. It is not dereferencing any pointers other than this (and I guess 'fromHost' if that's a reference), so I suspect you are chasing a red herring.

What I'd do first as a sanity check... is examine this in your watch window. If it's a bad pointer... then that's your problem. Go down on the call stack until you find the code first referencing this object and you'll find that it's trying to call a member function with a bad pointer.


If this is fine (which I suspect), then I think you're misdiagnosing the problem line. Go all the way up on the call stack and then examine all objects/pointers which are being dereferenced. One of them must be 0xcdcdcdcd.



EDIT: to clarify my terminology.. "up" on the stack would be more recently called functions and "down" would be previously called functions (stack grows up). So main() would be the bottom of the stack (or close to it).

I'm not sure if that's widely accepted. Some people might consider the stack to grow down.