I think my C++ application is tight and doesn’t leak any memory. Long running stress tests and static code analyzers seem to indicate as much. However, when exercising a very complex usage szenario the Visual Studio 2008 built in debug heap will show a couple of warnings like the following on exit:
Detected memory leaks!
Dumping objects ->
{318231} normal block at 0x03397FF8, 0 bytes long.
Data: <> üû
What is a memory “leak” of 0 bytes length? Am I corrupting the heap somehow? What could possibly cause the debug heap to emit a warning like that?
Seeing those “u” characters after the empty bracketed value is creepy. But looking at the CRT source code, that could be explained by a bug in the dumping code, it doesn’t seem to zero-terminate the string when the memory block is 0 bytes (valbuff variable in dbgheap.c).
Allocating zero bytes is otherwise a supported scenario. And your code not de-allocating it isn’t quite mysterious either perhaps. If you can get the number before the “normal block” output stable then you can assign _crtBreakAlloc() in your initialization code to force a breakpoint. Or you could set a conditional breakpoint on the CRT debug allocator. Trace into a malloc or new call to find it.