7

I have just resolved a memory leak in my application and now I want to write a unit test to ensure that this does not happen again.

I'm look for a way to detect the memory usage of the current application (working set), before and after some functions.

For example:

long mem_used= GetMemUsed(); 
/* Do some work */
/* clean up */

if( mem_used != GetMemUsed() ) {
    Error( "Memory leek" ); 
}

I have found plenty of ways to detect the memory usage across the entire system but none for just the current application.

Suggestions, links, code snippets?

Steven Smethurst
  • 4,495
  • 15
  • 55
  • 92

6 Answers6

6

Boost.Test will automatically tell you at the end of a test run if any of your unit tests leaked memory.

I don't know if any of the other C++ unit testing frameworks provide this kind of functionality.

Ferruccio
  • 98,941
  • 38
  • 226
  • 299
  • 2
    Support for memory leaks only on MS compilers: http://www.boost.org/doc/libs/1_44_0/libs/test/doc/html/execution-monitor/user-guide.html – Martin York Aug 24 '10 at 19:19
5

I really like ValGrind for this sort of thing. These tools already exist; you don't need to write your own unit tests to detect memory leaks.

Ed S.
  • 122,712
  • 22
  • 185
  • 265
  • 1
    Just make sure it is built into the unit test. Having to run valgrind by hand to validate the application will lead to lazy people not running the test. – Martin York Aug 24 '10 at 19:17
  • That sounds like a personnel problem, not a software problem. – Ed S. Aug 24 '10 at 20:01
  • @Ed: laziness is a person problem, we agree, but since you're forewarned, take it into account and, as Martin suggests, make it so that the easier way to run the test is also the one in which the memory leak detection is built :) – Matthieu M. Aug 25 '10 at 06:07
  • 1
    Ok, how about kicking it off automatically after a build? It shouldn't be difficult, we have a lot of separate test utilities that we launch after each build for our core input/output modules. – Ed S. Aug 25 '10 at 06:36
  • 1
    @EdS., I'd call it a resource usage issue. Each project only has so much developer time and attention. If you are spending developer time running testing manually, that's inefficient and takes resources away from adding features and fixing bugs... – Technophile Aug 13 '14 at 06:54
4

For Linux or other systems that use GLibC there are functions to get memory allocation statistics. Assuming no lazy allocations, you should have the same memory committed to malloc before and after you perform your test.

doron
  • 27,972
  • 12
  • 65
  • 103
  • 1
    The OP was asking about C++. malloc should not be used in a C++ context. – Michael Dorst Mar 12 '13 at 07:06
  • @Michael, this is true from a programmer's perspective but you will probably find that the C++ standard library defines `new` to use malloc under the hood. Malloc statistic are probably still relevant for leak detection. – doron Mar 12 '13 at 14:44
  • probably? I'd like to know for sure before I assume anything. – Michael Dorst Mar 12 '13 at 19:23
  • @anthropomorphic the implementation of new is platform dependent. Since the global new operator will probably be header only so you can check the code in your platform SDK. If not you will either have to browse the source or refer to the relevant platform SDK documentation. – doron Aug 24 '15 at 14:12
3

That is not a unit test. If you want to make sure some unit that is supposed to manage a resource does not leak that resource then you need to validate that the resource it is managing gets deleted at the correct times. You can do this with mock objects which increment a counter on construction and decrement on delete...then make sure the count is right.

A test that checks the memory usage of an entire application is not something for a unit test. Unit tests are for particular units within the application.

Edward Strange
  • 40,307
  • 7
  • 73
  • 125
  • What is the "That" in "That is not a unit test"? Running ValGrind? Thanks for the counted mock object suggestion! – Technophile Aug 13 '14 at 06:59
0

You can also use google test framework (gtest) and then use google performance tools (gperf) to find leaks. GPerf puts in a replacement memory library and if there is a memory leak found after the test run completes it will let you know and gives you a pprof command to run with several different output formats - text, dot, web, etc. This tool will find leaks in both tests and production code.

I also use Valgrind to confirm if there is a leak when questionable but prefer gperf. One gotcha is that if you have compiled with the gperf memory library and try to use Valgrind, it won't find any issues because it catches the leaks so you need to clean compile between switching or have a second copy of the project.

miteshyh
  • 43
  • 4
Steve
  • 1
  • 1
-1

ProcessExplorer (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) works well for that.

Russ
  • 4,091
  • 21
  • 32
  • 1
    I have been using this tool, but its a manual process this way. I was looking for a way to do it in code so i could add it to a unit test. – Steven Smethurst Aug 24 '10 at 19:10