Back to General and Gameplay Programming

Free Memory Leak Checker (C++)

Evil Steve · 2008-02-19T09:01:06

I've been meaning to tidy this code up for a while and then post it here, but I just never got around to it. Then, today MindWipe was having issues with the CRT memory leak code, so I decided to get of my ass and tidy it up and hand it over. The code was originally in my engine, and I've just removed the engine specific stuff really. So, here is MemMgr.h and MemMgr.cpp. It's a couple of files that you can just drop into any project, rebuild all, and you'll get free memory leak checking code and a few other bits and bobs. You don't need to #include "MemMgr.h" or anything. Example usage: int main(int, char**) { int* n = new int[42]; return 0; } That'll give you debug spew at application shutdown, and write to memleaks.log, then debug break. The debug spew is the same as you get in memleaks.log, and is (In this case): 1 active allocations totalling 168 bytes: + ID 00000002, tag ID 0x00000000: 0x00356B84 168 bytes [main.cpp:9 (main)] End of allocations The code only works on Windows, and should work fine on x64. It'll also only work on Visual Studio, due to my #pragma black magic. Only tested on VC2005 so far, but it should work fine in VC2003 or VC2008. A few bits and bobs: It uses a singleton for the memory manager (I know, I'm sorry to all the singleton haters out there), but I believe it's perfectly justified in this case. It uses some #pragma black magic to make sure the memory manager is one of the very first things created, and one of the very last things destroyed. That means it can correctly track STL memory leaks (Although you should only get them if you have e.g. a std::vector in a class allocated with new). This does mean that it might not play nicely in some cases. Please let me know if you find such a case. It does some stack walking with the StackWalk64() function to determine where the allocations came from when memory leaks are detected. It won't give you a full call stack, if you want that it should be straightforwards to modify the code. Instead, it just gives the first function on the stack that isn't in the memory manager, operator new, or STL code. It's thread safe. It only tracks allocations made with new or new[]. It won't handle malloc() allocations (Again, it could be modified to do that I suppose). There's some statistics code you can access if you #include "MemMgr.h" and then access the various functions, e.g. MemMgr::Get().GetAllocatedBytes(). The memory manager only compiles into a debug build. Release builds will use the normal operators new and delete. You could change this if you like, but I wouldn't advise it. I'm not sure if this topic should go in Your Announcements, but I figured more people would read it here, and it's a very programming related thing. If any of the mods disagree, feel free to move the topic. If anyone has any questions or problems with it, feel free to post here or PM me. If someone could give it a whirl on VC2003 or VC2008 too, that would be good. EDIT: Updated the code to do runtime linking to RtlCaptureContext; apparently the Platform SDK that comes with VC2008 doesn't know about it. Cheers, Steve [Edited by - Evil Steve on February 14, 2008 8:53:42 AM]

General and Gameplay Programming Programming

Started by Evil Steve February 14, 2008 08:14 AM

13 comments, last by TechnoCore 16 years, 2 months ago

Jan Wassenberg

1,000

February 19, 2008 12:50 AM

Quote:This intrigues me. At least I've never heard of such technique, most other memory managers need to be included at beginning.

The ones that require including at the beginning will typically use macros and redefine new/malloc, which breaks placement new and member functions that happen to be called free, etc.
The init_seg / __declspec(allocate) technique is useful for performing init before main, before constructors run, or even before the CRT modules are initialized. See http://blogs.msdn.com/larryosterman/archive/2004/09/27/234840.aspx for an explanation.

Incidentally, Steve overrides global operator new, which happens at link-time and requires no init, but the synchronization object and dbghelp do. BTW, another advantage of allocation hooks is that they are called while under the CRT _HEAP_LOCK, which goes a long way towards making a memory manager thread-safe without any further work.

Quote:The problem MindWipe was having turned out to be a genuine memory leak (GLUT never returning, so memory never being deleted), but I thought it was because some global was getting destroyed after the _CrtDumpLeakCheck (Or whatever the function is).

Ah, ok. You can pretty much rely on the CRT report because it has the final word on shutdown order.

Zipster: good idea. 28 MB in spite of this optimization, though? That is an excellent motivation for me to finish up the zero storage scheme :)

E8 17 00 42 CE DC D2 DC E4 EA C4 40 CA DA C2 D8 CC 40 CA D0 E8 40E0 CA CA 96 5B B0 16 50 D7 D4 02 B2 02 86 E2 CD 21 58 48 79 F2 C3

Boder

935

February 19, 2008 01:21 AM

Whoa, got some freaky deja vu. Probably from Jan Wassenberg's old post when he announced his manager and discussed some of the same issues.

Because Evil Steve, you haven't mentioned this before?

[Edited by - Boder on February 19, 2008 1:21:49 PM]

Evil Steve

2,021

Author

February 19, 2008 03:40 AM

Quote:Original post by Boder
Because Evil Steve, you haven't mentioned this before?

I've posted a similar memory manager before, but it was just straight from my engine code and needed tweaking to get it to compile; it was intended as a code sample for something or other, not something people can download and drop into their code like this.

Zipster

2,420

February 19, 2008 05:04 AM

Quote:Original post by Jan Wassenberg
Zipster: good idea. 28 MB in spite of this optimization, though? That is an excellent motivation for me to finish up the zero storage scheme :)

Yes, however I misspoke. It was the allocations we were storing in a hash map, and the stack traces were in a static array. This array was about 21 MB, and the hash map overhead was another 7 MB or so. However we did manage to fill the entire stack trace array on a few occasions, so ~28 MB was indeed in active use at those times.

I should mention that this was the usage we measured using the release CRT. The amount of additional information we stored with each allocation was much less than a debug CRT header, so there really wasn't much more voodoo magic we could do besides shortening the call stack depth or trying a different container. Believe me we could have used a few tricks, because we were running up against hard memory limits on our target platform :)

TechnoCore

122

February 19, 2008 09:01 AM

Quote:Original post by Evil Steve
"Kosher" meaning "normal" or "standard" singleton. A normal singleton constructs itself the first time it's referenced, E.g.:
*** Source Snippet Removed ***Or similarly, with dynamic allocation. In this case, the singleton is created and destroyed explicitly - the key point is that it's not constructed the first time it's used.

Singletons are usually considered a sign of bad design, since they're really just globals in disguise. See Promit's Journal for some relevant links.

Thanks for the clarification... you had me reading for a couple of hours there ;)

//TechnoCore

Free Memory Leak Checker (C++)

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Free Memory Leak Checker (C++)

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines