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]

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!

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.)