Is there any way of preventing application from crashing when heap is corrupted? - C programing language

Question

Hi,

Sometimes in execution I get this error message in VS2010 when trying to free memory:

Windows has triggered a breakpoint in [APPNAME].exe.

This may be due to a corruption of the heap, which indicates a bug in [APPNAME].exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while [APPNAME].exe has focus.

The output window may have more diagnostic information.

Wich means something is wrong with heap or pointer.

My issue is that this error crashes my app when it is built as a release.

Also this is just a module of bigger application and when this crashes everithing goes down.

I would like to be able to handle this error.

From msdn on "free":

If an error occurs in freeing the memory, errno is set with information from the operating system on the nature of the failure. For more information, see errno, _doserrno, _sys_errlist, and _sys_nerr.

There is a errno_t _get_errno( int * pValue ); function that returns error code.

If I press continue on the error msg shown above this function returns error code. Using this code I can detect error, create call stack and exit my function softly.

Is there any compiler switch or something to prevent aplication from crashing when free fails and allow me to exit it my way??

Answer 1

Theoretically you try to prevent your app from crashing using SEH. AFAIK "debug breakpoint" is a sort of a SEH exception, which can be handled.

__try {
    // do something here
} __except(EXCEPTION_EXECUTE_HANDLER) {
}

The above __try/__except block will catch all the exceptions (both C++ and SEH).

HOWEVER

I believe you should not do this. Heap corruption, as well as any other invalid memory access - is an bug Once this happens - the damage is usually unrecoverable. You may prevent the crash (hopefully), but you can not guarantee your program does what it should do. From now on it may crash at any other place.

Instead of preventing the crash I suggest you FIND the outlaw that dares to overwrite the forbidden memory and corrupt the heap.

Answer 2

Fix your code instead of trying to ignore such a serious error. You shouldn't have such serious memory bugs in your production code. AFAIK there's no simple way to handle this and it's for a good reason.

Btw, I thought the dialog appears only in debug mode. In release mode the memory error should not be detected and the application should crash immediately (or run with a corrupted heap, yuk).

Answer 3

If the heap is corrupted, all bets are off. Memory allocations may fail (unless they're on the stack), they might return pointers to wacky areas, and even existing stuff on the heap could be mangled beyond recognition. In such cases, you're actually better off crashing, as any action you take (even trying to gracefully exit) could just make things much worse.

Find the code that's mangling stuff on the heap, and fix or remove it.

Answer 4

Many Windows programs use HeapSetInformation with HeapEnableTerminationOnCorruption to ensure that the program crashes immediately when heap corruption is detected. This is a security measure, since heap corruption might be exploitable. Crashing immediately on heap corruption is the only sane thing to do.

But if you're trying to debug, and it's a release build, this setting can make it difficult to debug the problem. It sounds like you have a module that run inside somebody else's app (though I'm not sure from your description). In that case, it might be that the other application is setting the heap termination flag. Unfortunately, it cannot be unset once set (per process).

You'll need to attach a debugger to generate a dump file when the crash occurs and try to debug from that.