🔒 Locked

Memory leak madness!

Started by James Trotter Mar 27, 2005 at 8:28 AM 4 replies 3k views

Original Post

Mar 27, 2005 at 8:28 AM

Hi! Wow! Have I spent a lot of time scratching my head, or what? I decided to test if my application was leaking any memory. So, I did some searching and found a nice looking tool: LeakTracer. It worked in Linux, and I'm running gcc 3.4. I obviously had a lot of memory leaks, so of course the hunt began! It took me ages to narrow dome parts of it, and I was amazingly surprised when I did find out what was causing it. I actually didn't believe it: The tool was reporting errors when calling std::string's constructor. That's in the C++ standard library, there's no way someone could have slipped a (actually several) memory leak in there, without someone else noticing. (And I was highly doubtful that I might have been the first one.) So, I spent ages trying to figure it out! Eventually, I came up with this page that explains it all. std::string, (or more exactly std::allocator) is not leaking memory. What's happening is that std::allocator uses a special pool allocation scheme, and overloads the new/delete operators. (Actually I'm not entirely certain that's how it's done, but something like that, anyway.) The memory leak detection tool didn't realize this, and reported leaked memory. The solution I found was to use another, much better tool: Valgrind, which actually handles this stuff correctly. It realizes that std::allocator is not leaking memory. It also has a much nicer interface than any of the other tools I've used. Well, this post is just a heads up to anyone looking for a memory leak detection tool. I recommend Valgrind to save you from pulling out your hair in endless frustration. Cheers, and hope this helps someone! Edit: I should probably have mentioned that Valgrind is currently only supported on Linux (2.4 kernels and up, with glibc 2.2 and up) and FreeBSD. [Edited by - James Trotter on March 27, 2005 8:46:17 AM]

IFooBar

Mar 27, 2005 at 8:53 AM

You might also want to give Paul Nettle's memory manager a test run.

Mar 27, 2005 at 8:55 AM

Just FYI: I have been using MMGR by Paul Nettle. I liked it. It also works on Windows, and the only thing you have to do is #include "mmgr.h" after including stdlib files and before including your files.

But thanks for the link to Valgrind! Looks nice aswell.

James Trotter

Mar 27, 2005 at 9:07 AM

I've been using Paul Nettle's memory manager for a long while. I believe it has the same problem as LeakTracer, with std::allocator. I seem to remember, (possibly due to the std::allocator stuff) that it had certain incompatabilities when used with std::fstream.

It is nice, yes, and I found it useful for a long time. However, I'm going to recommend, that you should, if you can, use Valgrind instead. And in the case of valgrind, there is no need to include any headers at all. You simply need to run Valgrind on the command line with your program as an argument, and it will give you all the information you need. There's documentation at the Valgrind link above.

Cheers!

Toolmaker

Mar 27, 2005 at 9:16 AM

Quote:
Original post by James Trotter
I've been using Paul Nettle's memory manager for a long while. I believe it has the same problem as LeakTracer, with std::allocator. I seem to remember, (possibly due to the std::allocator stuff) that it had certain incompatabilities when used with std::fstream.

Cheers!

If you would have read the documentation, you would have seen that the problem can be easily by-passed. Include all STL libs ABOVE the include to MMGR, and you'll never see the std::allocator allocated memory.

An ever better solution is to stuff all STL headers into a precompiled header(Saves you some compile time too), and then include mmgr after that:

// stdafx.h#include <vector>#include <string>#include <sstream>using std::string;using std::vector;using std::stringstream;// Any other .h#include "stdafx.h"#include "mmgr/mmgr.h"// Code here

That would just fix the problem and it would work fine.

Toolmaker

James Trotter

Mar 27, 2005 at 1:01 PM

Quote:
Original post by Toolmaker
Quote:
Original post by James Trotter
I've been using Paul Nettle's memory manager for a long while. I believe it has the same problem as LeakTracer, with std::allocator. I seem to remember, (possibly due to the std::allocator stuff) that it had certain incompatabilities when used with std::fstream.

Cheers!

If you would have read the documentation, you would have seen that the problem can be easily by-passed. Include all STL libs ABOVE the include to MMGR, and you'll never see the std::allocator allocated memory.

An ever better solution is to stuff all STL headers into a precompiled header(Saves you some compile time too), and then include mmgr after that:
// stdafx.h#include <vector>#include <string>#include <sstream>using std::string;using std::vector;using std::stringstream;// Any other .h#include "stdafx.h"#include "mmgr/mmgr.h"// Code here
That would just fix the problem and it would work fine.

Toolmaker

Wow, thanks! I'll keep that in mind if I decide to use Paul Midnight's memory manager again. (Likely if I'm porting to Windows.)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.