Memory leaks - part 2

In my last post I introduced UMDH and talked about how it uses snapshots to find memory leaks. In this post I'd like to talk more about how to use it and more importantly tips for improving accuracy.

The output from UMDH is organized with the largest leak at the top and the smallest at the bottom (measured by bytes leaked not the number of times the leak occurred). This is great because if you start at the top and work your way down you'll get the most bang for your buck.

An output entry from UMDH contains several things like the total number of bytes leaked, the number of times the allocator was called without being freed, and most importantly the call stack of the allocation. If you don't have an accurate call stack then check your symbols and make sure you ran the gflags command I mentioned in the last post.

UMDH's greatest attribute, it's ability to capture memory leaks, is also it's greatest weakness. It captures so many memory leaks that you'll get tons of false-positives. This is because Windows is doing stuff under the covers you're not aware of, and this shows up as potential memory leaks in UMDH. My rule of thumb is if the call stack doesn't contain any of my code, I ignore it. Also, just because my code is in the call stack doesn't means it's valid either. So I won't spend too much time investigating a problem. It just takes practice to be able to know what's valid and what's not.

By far the best tip for improving accuracy is to run the program for as long as possible, and separate the time between snapshots as long as possible. What this does is make your memory leaks larger which means they are higher up in the UMDH output file. For example, if your program is a service, take a snapshot Friday before leaving work and take the other snapshot on Monday morning. Also, make sure the program is doing something during this time period. The more it's doing the more likely it is to leak, the larger the leak the easier it is to detect.