Debug heap memory leak detection - strange results?

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.

Argh. Nevermind I found it. A statically linked library was allocating arrays of length 0 via new[]. This would have been ok I guess if it also used delete [] to kill it. However, the delete call was conditional and only happened if array size > 0.