Debugging leaked objects


I’m struggling to debug a leaked object reported on shutdown:

*** Leaked objects detected: 575 instance(s) of class ColourGradient

There is no way I have that many instances of ColourGradient in my app… and all those used are instantiated via e.g.:

            ColourGradient backgroundGradient (Colours::black, 0, getHeight(),
                                               Colours::grey, getWidth(), 0, false);
            g.setGradientFill (backgroundGradient);

Any tricks people can recommend to debug this?


Grep for “new ColourGradient”, I guess… and look for other classes that may contain one, and which may themselves be getting leaked.


If you press continue in the debugger, it will report other objects you leaked and maybe you recognise one of them?

Jim also wrote a tool to give stacktraces of leaked objects which I’ve found useful in the past:


Thanks for the suggestions, will try those, and I’ve already used one of Jim’s debugging tools in the project so I’ll give the advanced leak detector a spin, cheers


So I think its to do with the SVG parser. Below is a typical chunk of my GUI code.
I’m wondering if each Drawable given to setImages needs to be a ScopedPointer rather than passing the returned pointer from createFromSVG?

        ScopedPointer<XmlElement> playSVG (XmlDocument::parse (BinaryData::Play_svg));
        ScopedPointer<XmlElement> playPressedSVG (XmlDocument::parse (BinaryData::Play_Pressed_svg));
        ScopedPointer<XmlElement> playOverSVG (XmlDocument::parse (BinaryData::Play_Over_svg));
        playAllButton->setImages (Drawable::createFromSVG (*playSVG), Drawable::createFromSVG (*playPressedSVG), Drawable::createFromSVG (*playOverSVG));


edit :
your drawable has to be ScopedPointer stored in a class i least ive been doing that


Hard to track down leaks have been diagnosed quickly here using the Clang LeakSanitizer and AddressSanitizer on Linux. I think it is available in XCode on Scheme/Diagnostics page too.


RAM is cheap luckily… :slight_smile:


Maybe another tip: When you hit the first leaked object assertion, let the program keep running, as you’ll probably get more, with different objects, that will make it clear what’s going on. I was kind of assuming you’d done that and were posting here because only a ColourGradient was leaking, which would be very odd, but maybe that’s not the case.


Thanks @do.while, making my (many!) Drawables into ScopedPointers is doing the trick. VIM macros to the rescue!!


If you’re on Windows, I found the _CrtSetBreakAlloc(allocationIndex) function to be incredible useful for tracking down leaks (even for those who slip through the crack of JUCE’s leak detector).



does that break after the nth allocation then?

Also - Application Verifier is pretty essential on Windows if you’ve not got it yet…


I just use the allocation number from the leak report that is shown after
terminating the debugging session - this just works with "deterministic"
programs which always allocate in the same order though…