"Heap Corruption detected..."

[Tzarls]

I'm getting this message when exiting my app:

"HEAP CORRUPTION DETECTED: after Normal Block (#1039) at 0x0266D348. CRT detected that the application wrote to memory after end of heap buffer."

0x0266D348 is the address of a certain object I create from inside the app. I've placed breakpoints at that point of memory to monitor when it is being changed and I've detected that it is being written when the object is created (of course) and when it is deleted. Just after the members of that object are destroyed (some vectors which are not even being used, strings and pointers) operator delete() is called, and it calls _free_dbg(...) which calls _free_dbg_nolock(...) which shows the error message. No other process writes to that point of memory as far as I can tell.

Any idea to help me find the error will be greatly appreciated.

[mystran]

Normally such a message means you are writing past the bounds of an array. This could be as simple as single byte off. Pretty much the only other thing would be a double free or something, but those should normally trigger different messages from debug heap.

[Music Engineer]

Normally such a message means you are writing past the bounds of an array.

indeed. but am i completely off, when i seem to remember that some years ago (maybe it was with VS 2005 or something), we got access-violations directly at the moment when such an invalid access occurred?

[Borogove]

Normally such a message means you are writing past the bounds of an array.

indeed. but am i completely off, when i seem to remember that some years ago (maybe it was with VS 2005 or something), we got access-violations directly at the moment when such an invalid access occurred?

You get an immediate access violation if you access memory that the operating system thinks doesn't belong to the application. In this case, you're writing to memory that does belong to your app, so the operating system doesn't know or care. Within the app, there's another layer of memory management, and in this case that layer's error checking is catching the error.

The details are complex, but in general, small overruns (like off-by-one errors) are usually not going to be caught by the OS, but if you overshoot a buffer by a megabyte or two it's much more likely you'll get the access violation.

[cpr]

Maybe Visual Leak Detector will give you a more verbose report on the error? http://vld.codeplex.com/

[jobromedia]

Arrays huh. I bet you've done a common mistake writing one over the array boundries. Here's some pseudo-code:

Code: Select all

dim array 20
for i = array(1) to array(20) step 1
 array(i) = 0
next

Replace with this code:

Code: Select all

dim array 20
for i = array(0) to array(19) step 1
 array(i) = 0
next

[mystran]

Normally such a message means you are writing past the bounds of an array.

indeed. but am i completely off, when i seem to remember that some years ago (maybe it was with VS 2005 or something), we got access-violations directly at the moment when such an invalid access occurred?

Only if your access crosses a page-boundary to an unallocated page. There are some debug libraries that can arrange for this to always happen (eg I've used ElectricFence on Linux) but MSVC debug heap unfortunately doesn't do it. Instead it writes all allocated memory with known patterns and checks afterwards that the data is what it should be.

[Tzarls]

Thanks for the ideas. Now, it's not an out-of-bounds array problem, at least as far as I've been able to check. I'm using vectors for the most part, so any out of bounds operation on them would be caught by the vector anyway. I'll check if VLD can help here... any other ideas or suggestions? I've seen Valgrind mentioned for this kind of problem.... since my code is crossplatform, I guess I could debug this in Linux...

[jobromedia]

1. So what is the object that is created?

2. My advice would be to create a BeforeDestroy function inside the object that disables the memory routine before it is being destroyed to at least try to prevent this ugly bug showing up it's rear.

[mystran]

2. My advice would be to create a BeforeDestroy function inside the object that disables the memory routine before it is being destroyed to at least try to prevent this ugly bug showing up it's rear.

That's certainly the wrong approach. For one, production libraries never give those errors anyway (it's just the debug heap that does such checks) and for another it's likely that there is something wrong going on, and it's entirely possible that in a slightly different configuration or maybe depending on random things like exact addresses of heap allocations it could cause an actual crash.

It's almost never a good idea to cover up any bugs, unless you are sure that there's no way you can actually fix something (eg platform API bugs; can't do much about those) and you really understand what's going on and all the possible implications and failure modes of the work-around.

[jobromedia]

Maybe so, but to me it sounds like your plugin / app reads from memory it shouldn't be reading from in the first place. My advice would be to apply this method anyways. In it you'll undim all variables and arrays as well as wipe out all resources so you don't have any memory leaks. I'm no expert, but to me this problem sounds like you got a leak somewhere.

[safiire]

Maybe so, but to me it sounds like your plugin / app reads from memory it shouldn't be reading from in the first place. My advice would be to apply this method anyways. In it you'll undim all variables and arrays as well as wipe out all resources so you don't have any memory leaks. I'm no expert, but to me this problem sounds like you got a leak somewhere.

This is not about memory leaks, this is about the debug heap doing you a favor upon process termination and letting you know you've smashed over some canary value it uses to determine if you have written to an address that is owned by your process but was not allocated by new or malloc etc.

It indicates a really annoying type of error where you can't tell where you've done this, because it doesn't let you know immediately, but only when your process ends.

An oldschool no-tools way to track this down, that is if you can reliably get this error to occur, is to gradually comment out parts of methods in that class until it stops happening, then add them back until you add the part which is causing it.

That is, if this object is actually responsible.

[stratum]

If you are using both debug/release versions of the visual c++ runtime in the same project, then it may cause heap corruption in some cases especially if a block allocated with one of them is deallocated with the other version.

[yeahtuna]

Could you possibly be trying to delete a pointer that was never really set?

[Tzarls]

I've carefully checked all pointer deletion (searched for EVERY "delete" word on the entire projectm then set break points around the relevant ones) and nothing. BUT I've found this:

http://forum.codecall.net/topic/64948-s ... udio-2010/

Not a solution to my problem but something very similar to whatI'm experiencing...