The reason you will receive "corruption of the heap" error message only while running under the debugger is that the heap is helping you while you are in the debugger.
Specifically, the Windows CreateHeap()
function will check to see if the process is being debugged. If so, the equivalent of calling SetHeapInformation()
with flag HeapEnableTerminationOnCorruption happens. This is provided to you as an assistance in finding and debugging heap corruption. It is not provided at all times, because there is a performance penalty associated.
If you attach the debugger after program start, rather than launching the program from within the debugger, the CreateHeap()
call will already have passed and the heap will be operating in the normal mode.
Heap corruption is caused by writing beyond the boundaries of a block returned from the heap. For example, copying a 16-byte string into an 8-byte allocation. Beyond the boundaries of the blocks returned from the heap are structures used by the heap data structure. For example, linked-list pointers might be found surrounding the allocated bock.
When your program writes beyond the boundary of the block, it might or might not hit the surrounding information and cause a crash. With a heap overrun in your program, it might be hard for you to detect. Then on a user's machine, that heap overrun might always lead to a crash.
In order to spare you the embarrassment of releasing code with heap overruns, the CreateHeap()
API is trying to help you, by configuring the heap to give you more information.
I can't tell you what you need to do with OpenCV to make this work, however. Are you sure there isn't some other setup routine you need to call prior to cvNamedWindow()
.
In the debugger, are you able to set up a breakpoint on the API which displays the termination message? Try setting a breakpoint on the FatalAppExit()
and ExitProcess()
APIs to see exactly when the heap is generating its complaint. Is it before or after the call to cvNamedWindow()
?