Memory leak detection during unit tests

Question

I have a Win32 C ++ application with a set of unit tests. After the unit tests are over, I would like to automatically create a report that could be read from any free memory. Ideally, the report will have a stack with files and line number information for each disparate selection. It would be nice if they were generated in sequential order, so that it is easier to distinguish them from one pass to the next. (Basically, I would like the results of valgrind --leak-check = full, but on windows).

I had success when UMDH received this information from running processes, but this tool only works if you join an existing process. I want this to happen automatically every time I run unit tests.

Is there a tool that can do this? If so, how to use it?

Thanks!

Answer 1

I played with the CRT Debug Heap functions that Mike B pointed out, but in the end I was not happy with just getting the address of the leaked memory. Getting stacks like UMDH makes debugging much faster. So, in my main () function, now I run UMDH using CreateProcess before and after running the tests to get the heap snapshots. I also wrote a trivial batch file that runs my test harness and then expands the heap snapshots. So, I run the batch file and get the results of my tests and a text file with full stacks of any disparate distributions in just one shot.

UMDH collects a lot of false positives, so maybe some kind of hybrid of CrtDebug material and what I'm doing right now would be the best solution. But now I am satisfied with what I have.

Now, if I had a way to detect if I had closed any pens ...

Answer 2

To get this information, we override new / delete and malloc / free, providing our own heap implementations that store stacktraces during distribution and generate a report when the heap is destroyed (as well as adding sentinels to detect buffer overflows).

This is honest work the first time you do it. This guy wrote a free tool that handles all hard bits - I have not tried it myself, but his explanation of how he wrote it is useful when you ride on your own.

Answer 3

If you use MSVC, the Microsoft Debug heap functions can be used to create the required report, but it may not be as automatic as you would like (you may need to write some custom code):

_CrtSetReportMode _CrtSetReportFile _CrtMemState _CrtMemCheckpoint _CrtMemDumpStatistics _CrtSetReportFile _CrtSetDbgFlag 

Answer 4

You can define DEBUG_NEW and enable leak detection, you need to define it before including any files with the system. It only checks for leaks with the new operator and, of course, you have to recompile your code so as not to add it as valgrind.

See here for more details:

http://msdn.microsoft.com/en-us/library/tz7sxz99(VS.80).aspx

Answer 5

I did it once, but it was not so simple. Now I do not have access to this code, but here is the idea:

I used the debugging features that Mike B was talking about (by the way, they only work in Debug).

The test drive ran all the tests twice, because during the first run, memory is allocated for global variables. The second time, the total number of allocated blocks was checked before and after each test (I think you can do this in setUp () and tearDown ()). If the number was different, it meant a memory leak, and the test failed with the appropriate message. Of course, if the test itself fails, you should save its error message. Now, to find the leak, I had to read the allocation number of the last distribution block using pBlockHeader, and then set a breakpoint on it using _ CrtSetBreakAlloc and run it again.

More about this here: http://levsblog.wordpress.com/2008/10/31/unit-testing-memory-leaks/