Does anybody have any tips for catching memory leaks? The JUCE memory leak catcher usually only tells you want object has leaked, ie, a String or a Component. Is there anyway to get more detail, like which Component it is?
There are a couple of good leak detector classes you can little just drop into your project and they give back all the info that the typemap’s supply, usually into a log file, and of course the detector disappears in release mode by default…
I’ve kind of… borrowed the one from Ogre for most of my things.
Search for visual leak detector under codeproject.com [free]
Or you can also test Memory Validator (google is your friend) [shareware].
The modalComponentStack and the modalComponentReturnValueKeys are creating false positives. I’m assuming its because they are static objects and they get deconstructed after the memory leak scanner has already run. It would be nice if they where DeletedAtShutdown so they didn’t cause false positives.
{Dup - post}
I’m wrestling with a possible leak at the mo (keeps showing up as in something that uses the Message class!).
(Setting a data break-point on _crtBreakAlloc to the reported value doesn’t really help - I guess because the order they’re created/destroyed isn’t identical on any 2 runs!) - Yuch
In the past (and in Delphi) - there was a dead handy Mem Management replacement unit (class, to you!) which stored a stack trace of every malloc/realloc/calloc/free… Sounds memory hungry , I know, but it was very useful !
When a block had been alloc’d but not freed (for example), it listed where the block was alloc’d and you then just had to work out where the block should have been freed/relinquished… Litter the free area with debugs, and squash the bug! :x
I had a little look around for an equivalent in crt, but I haven’t found anything yet
I guess you haven’t read what I’ve written earlier.
Get VisualLeakDetector and you’ll get a stack trace for every allocation in your software.
No, I missed that - I was just wandering about, and thought I’d ad my twopence worth… Cheers, I’ll take a look
I recently had a few leaky issues of my own (get those puns out of your head!)
And hunting around I found this gem: Only VS2008, AFAIK
When Juce reports a memory leak (MS build):
Make a note of the value in the curly brackets. and see if you can make sense of the values in leaked (e.g. may be a string or filename *)
Click on the address where the leak is reported and insert this line of code immediately after the reported line:
_CrtSetBreakAlloc(value in curly brackets);
Re-run (debug) the debug version. The code will break at the line. Check though the stack frame checking for any clues gathered earlier*
Hope someone finds this intelligible and useful.
BTW - I’ve also added this:
#define juce_UseDebuggingNewOperatorLEAK(X) \
static void* operator new (size_t sz) { void* const p = juce_malloc ((int) sz); return (p != 0) ? p : ::operator new (sz); _CrtSetBreakAlloc(X);} \
static void* operator new (size_t sz, void* p) { return ::operator new (sz, p); _CrtSetBreakAlloc(X);} \
static void operator delete (void* p) { juce_free (p); }
Just below the usual juce_Memory.h definition
Now if that juce_UseDebuggingNewOperator definition is highlighed, I just replace it with juce_UseDebuggingNewOperatorLEAK(value in curly brackets)
P.S. Don’t forget to add the equivalent blank definition in the release version of the definitions 