I bet the one that has posted that message has some library linked to that simple code that actually causes the heap corruption as the delete call is only a chance for the crt to detect the problem, which might have occurred much earlier, even before main() is called..

Ah the dreaded "Heap Corruption Detected" error! Usually I try to squash these as soon as they come up. If you do proper RAII everywhere and minimize the raw access to pointers, along with liberal use of assert macros, these will be infrequent.

If and when they do pop up, you should immediately address it: the longer you let it linger, the harder it will be to track down. The prime suspect, a.k.a. "first place to look" should be whatever code you changed since the last run that did not contain the memory corruption.

Other than that, you'll have to experiment with changing the app to come up with the minimum code path that reproduces the problem and then perhaps doing an exhaustive search through the remaining code.

These guidelines apply to tracking down memory leaks as well.

Microsoft Application Verifier can be useful for catching stuff like this. When it's active while using a debugger, you should get a debug break where the heap corruption first occurred.

It saved me some time this weekend when the debugger pointed at a heap corruption somewhere deep down in fclose() with a stack trace unrelated to the real error. With AV enabled I got a debug break where the error had actually occurred, which in my case was a misfiring callback that updated a structure that just got deallocated.

It's a good tool, might be worth a try if you're using Windows.

This all depends on how you are accessing the vector. If you are using vector<T>::operator[]() you may be surprised to know that you will receive no indication (other than an access violation) when accessing your vector out of bounds. Use vector<T>:at() and you'll be in good hands... after you add appropriate try-catch blocks.

Well I have to say that it is not very often that I add a new tool to my programming toolbox, but I tried this "Microsoft Application Verifier" and it is quite handy! Thanks!

Sorry for being so explicit, but if you have many spread deletes across your code it's very possible that you are writing brand new C++ legacy code.

As said, when not possible to use the stack, it is better to use RAII as much as possible, things like std::auto_ptr (deprecated in C11x), boost::shared_ptr and boost::weak_ptr in the old standard. If using a C11x capable compiler and possible to use c11x features you could use std::unique_ptr, std::shared_ptr etc...

Smart pointers are a must, they simplify life a lot. Explicit deletes should be left for when you are doing very advanced and unusual allocations like implementing your own memory pool, implementing an std::allocator etc... In the most mundane cases a modern C++ app shoudn't contain a single explicit delete call.

Anyways, if the issue is a memory access fault it's not necessarily a delete what you should look after, but anything that can leave a dangling reference or pointers.

It could even be something like a pointer to a element in a container like a vector that had more values inserted after storing the pointer and then needed to resize, moving all its content to a new memory location and invalidating all the pointers.

I largely stopped using smart pointers when I learned how to do RAII.

Which were the drawbacks?

After all smart pointers are a particular case of RAII when heap allocating.

Hey guys, thanks for all the replies. I haven't been able to touch the problematic code for the last few days, but I'm taking note of all the suggestions posted here. Keep the ideas coming! I'll test them on my app as soon as I can sit in front of my PC.

Well, actually "kinda" I lied.

I do use COM-style reference counting (with objects themselves keeping a reference count, such that you can have "multiple owners") for some things. I generally find this easier to deal with than typical "intelligent" smart pointers (including those in the standard), but you could rewrite the required rules into a set of pointer types if you wanted. In any case, even here I still have "RAII" style owners; it's simply that any particular object can have more than one of them.

Currently I do this for some graph-rewriting stuff where callers generally can't predict whether callees need to keep references around; every once in a while I wish I'd used a garbage collector here, but it turns out that reference counting bugs (which in my application can be sanity checked for) are pretty good at indicating other bugs.

Anyway, for the large majority of situations (including anything my plugins currently do) I find that it's usually possible to structure things such that there is always a clear owner that outlives the objects it allocates. In this case smart pointers are simply redundant, because you can just as well pass around raw pointers (or even references). In some cases this requires one object to request a pointer to another object from a third-party every time it wants to access the object, but in practice it's almost never in any code where an indirection was a significant issue.

The same code runs smoothly under Linux. I've tried Valgrind to find any heap corruption and can't find anything wrong... so maybe I don't know how to correctly use Valgrind ( ) or the Windows version of the libraries I'm using have some issues... but I just found that this project works fine when compiled using VC2008 but not when using VC2010... I wonder if...

...I'll be back...

If you have anything compiled with VC2008 and then using the binary with VC2010 it might be the cause of the problem if the libraries expose c++ interfaces (especially if these are supposed to be used with "new" or "delete" operators or throw exceptions) or not designed with proper memory management considerations. COM style interfaces should be OK on the other hand, as these are correctly designed with respect to binary/memory management compatibility requirements. C style interfaces are OK as long as "the one who allocates is responsible for deallocating" rule is not broken.
Last edited by stratum on Mon Aug 06, 2012 11:09 pm; edited 2 times in total

It could be that your Linux and VC2008 runtime just aren't as good enough as VC2010 in spotting this type of heap corruption. You can test that by doing something simular (but subtle) deliberately and see weather it gets detected in the other runtimes.

I used to be a mainframe developer (Cobol, PL/1) for decades and the things that could go wrong in memory there, quite hard to reproduce in modern languages like Java. Often the last resort was to actually look at the offending raw data in memory and figure out from the content, trying to recognise its structure and think of where it could origin from.

Valgrind USUALLY should find basically anything, since it essentially runs the whole thing in an interpreter. Most likely the bug is in some code-path that either doesn't exist or never gets called in the Linux case.. or alternatively it's a multi-threading race condition that happens to be trigger with particular runtime library while not with another.

In the PC used to develop with VC2010, all libraries have been compiled under VC2010, so that shouldn't be the cause of the problem.

Now thing get weirder. I've cut down the code to this:

int main(void)
{
   scriptCompiler *c = new scriptCompiler(0);

   delete c;

   return 0;
}

And it still fails!!! Using winDbg, it even fails in the middle of the scriptCompiler constructor (access violation)... And this is all working in my other PC when built under VC2008. And this project worked fine previously under VC2010... I don't know if this could be the cause of the problem, BUT...

... I had this project being developed mainly using VC2008. For one particular piece of (optional) code I needed VC2010, so I had it setup on a second PC. I copied all my sources to this new PC, rebuilt all my libraries using VC2010, then created a new solution for my project under VC2010, the added all the sources and built and everything ran just fine. Then, in my VC2008 project I had some major reordering of things to correctly separate the "core" code from the GUI code (the reordering had more to do with the location of files than with actual changes in code). When I tried to get those changes to my VC2010 project, I thought that instead of trying to remove and insert all the files by hand, it would be a better idea to just let VC2010 convert the original VC2008 solution. That's when the project started to have problems... could that be the source of the problems? I guess I'll have to try and create a new VC2010 project from scratch and add all files and configurations...