Question

I am writing a custom textfile-data parser (JSON-like) and I have lost many hours trying to find a tiny memory leak in it.

I am using VC++2008 and the commands _CrtMemCheckpoint and _CrtDumpMemoryLeaks to check for memory leaks.

When I parse any file and then remove it from memory (alongside any other memory claimed), I get a 16 bytes memory leak which looks like this :

{290} normal block at 0x00486AF0, 16 bytes long.
Data: <  H `aH  hH  eH > C0 9A 48 00 60 61 48 00 18 68 48 00 D8 65 48 00

I have managed to narrow the "offending" line of code down to this :

classDefinitions[FastStr(cString)] = classDef;

classDefinitions is an std::map<FastStr, FSLClassDefinition*> and is a private member of my parser class.

FastStr is a simple char* "wrapper" for allowing simple c-strings as key values; it has no memory leaks (no ‘new’ commands). ‘FSLClassDefinition*’ is obviously a simple class pointer, so nothing strange there either.

Now here is the catch :

1. this line is executed many times during the parse-process, but I only get a single 16-bytes block leaked.
2. if I parse another file, there is not another 16-bytes memory leak
3. If I remove the parser from memory (by having it in a {} code-block), then recreate it in another code-block and have it parse another file, then I get a second 16-bytes memory leak.

This leads me to suspect that there is a memory leak in std::map; but it could also be my mistake… I am pretty sure that’s the offending line because if I stop the parsing before it, there is no memory leak; there is memory leak if I stop the parsing just after this line.

Can anyone comment on this?

Answer 1

The "{290}" in the leak report is the sequence number of the memory allocation for the memory block that was leaked. If this sequence number is always the same, you can use _crtBreakAlloc to cause a break in the debugger when that allocation sequence number is hit. From the stack trace you can find out where this block is being allocated. Once you know where, and for what purpose, it is being allocated it tends to be fairly easy to determine why it is not being deallocated.

Read the Debug Heap documentation to learn about _crtBreakAlloc.