views:

495

answers:

5

Good afternoon all,

What I'm trying to accomplish: I'd like to implement an extension to a C++ unit test fixture to detect if the test allocates memory and doesn't free it. My idea was to record allocation levels or free memory levels before and after the test. If they don't match then you're leaking memory.

What I've tried so far: I've written a routine to read /proc/self/stat to get the vm size and resident set size. Resident set size seems like what I need but it's obviously not right. It changes between successive calls to the function with no memory allocation. I believe it's returning the cached memory used not what's allocated. It also changes in 4k increments so it's too coarse to be of any real use.

I can get the stack size by allocating a local and saving it's address. Are there any problems with doing this?

Is there a way to get real free or allocated memory on linux?

Thanks

A: 

Not a direct answer but you could re-define the ::new and ::delete operators, and internally either via a singleton or global objects, keep track of the allocated, and de-allocated memory.

Edit: If this is a personal, DIY project then cool. But if its for something critical you can always jump onto one of the many leak detection libraries/programs available, a quick google search should suffice.

DeusAduro
I had hopes there was an light weight easy answer. I'd like to keep the unit testing easy and fast. Valgrind looks like pretty good if I don't find something easier though. Thanks
Jay
+4  A: 

Your best bet may actually be to use a tool specifically designed for the job of finding memory leaks. I have personal experience with Electric Fence, which is easy to use and seems to do the job nicely (not sure how well it will handle C++). Also recommended by others is Dmalloc.

For sure though, everyone seems to like Valgrind, which can do just about anything and even has front-ends (though anything that has a front-end built for it means that it probably isn't the simplest thing in the world). If the KDE folks can recommend it, it must be able to handle just about anything. (I'm not saying anything bad about KDE, just that it is a very large C++ codebase, so if Valgrind can handle KDE software, it must have something going for it. Though I don't have personal experience with it as Electric Fence was always enough for me)

Adam Batkin
I'd have to definitely recommend Valgrind for this. It's a very powerful tool and relatively easy to use. For the purpose of finding leaks all you'd do is run "valgrind --tool=memcheck --leak-check=full ./TestProgram args" and read the report.
Falaina
I agree - make your unit test script run the program under valgrind and parse the valgrind report to look for memory leaks - as a bonus you'll also find out about other memory bugs too, like double-frees and invalid use of freed blocks.
caf
I'm definitely going to add this to the test regimen. Thanks for the recommendation
Jay
+2  A: 

don't look a the OS to get allocation info. the C library manages memory internally, and only asks the OS for more RAM in chunks (4KB in your case). In most cases, it's never released to back to the OS, so you can't really check anything there.

You'll have to patch malloc() and free() to get the info you need.

Or, use Valgrind.

Javier
+1  A: 

I'd have to agree with those suggesting Valgrind and similar, but if the run-time overhead is too great, one option may be to use mallinfo() call to retrieve statistics on currently allocated memory, and check whether uordblks is nonzero.

Note that this will have to be run before global destructors are called - so if you have any allocations that are cleaned up there, this will register a false positive. It also won't tell you where the allocation is made - but it's a good first pass to figure out which test cases need work.

bdonlan
This is simple, light weight, and fast. It gets the job done for both new and malloc when using the gnu compiler. It makes a great way to quickly point out the code that needs some attention. I'm sure with the help of valgrind it will make my code much better. Kudos!
Jay
A: 

google-perftools can be used in your test code.

fnieto