Monday 19 September 2011

When is a Leak not a Leak?


I received an email recently pointing out that HexEdit has memory leaks.  If you build and run the debug version of the new HexEdit 4.0 beta then when the program exits the debug heap spits out many messages about memory "leaks".  I have tracked down several of these "leaks" and it turns out they are not really leaks but one-off allocations for singleton objects.  This is not really a leak but better described as a "splash".

I think it is pretty poor of the MS CRT (Microsoft C run-time) to pronounce all non-deallocated memory as "leaks", especially as the CRT itself does one-off allocations (eg for the FILE table) but uses a special flag so that it's own "leaks" are hidden.  Often it is harmless or even desireable to not deallocate one-off objects.  But when the CRT debug heap uses the word "leak" it seems to create panic in some people who should know better.

I am pretty diligent about avoiding memory leaks.  Here I define a leak as a continual loss of memory during the running of the software (or some part or parts of the software) that eventually will result in memory exhaustion.  Typically this occurs when a function allocates an object on the heap but forgets to free it when it returns to the caller, leaving an unused but allocated block of memory.  Every time this function is called more memory is lost.

In modern C++, using auto_ptr and the like, it is fairly easy to avoid accidentally doing this.  Some of HexEdit was written before the advent of auto_ptr though; nevertheless I believe there are no such leaks in HexEdit.

My point is that I am not too bothered about all the messages about leaks from the debug CRT.  At various times I have tracked down many of these and they have always turned out to be harmless splashes.

However, I have worked in teams where the managers insists that all such "leaks" are fixed.   And if you have developers who are prone to introducing leaks then that is probably a good idea.  That way, when you do get a real leak it is not hidden amongst all the other bogus "leaks" in the debug CRT leak report.

On the other hand I have seen software which allocates a lot of global data (caching large amounts of data for performance reasons).  Insisting that all the objects on the heap are freed at program exit can mean that the program takes several minutes to exit.  In this sort of situation it is simpler and faster to simply exit and let the CRT/OS tidy up.

VLD

Anyway, I will endeavour to tidy up all the "leaks" in HexEdit.  Luckilly, there is a library that makes this easy, often trivial, to do.  See http://vld.codeplex.com for more information.

If you have ever used the MS CRT debug heap to try to track down memory leaks you know that it can be extremely tedious, sometimes nigh impossible.  The problem is that, although it tells you where the allocation was made, it tells you nothing of how the flow of control got to that specific allocation.  For example, there could be thousands of CStrings used in a program and there may be just one that was not deallocated.  Sometimes the contents of the memory (eg the text in the string) may give a clue but not always.

The beauty of VLD is it provides a "call stack"  that allows you to very quickly track down the problem piece of code.

No comments:

Post a Comment