Debugging leaked objects

General JUCE discussion
1

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?

2

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

1 Like
3

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: https://github.com/jcredland/juce-toys/blob/master/jcf_debug/source/advanced_leak_detector.h

1 Like
4

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

5

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));
6

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

1 Like
7

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.

8

RAM is cheap luckily… :slight_smile:

9

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.

10

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

1 Like
11

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

1 Like
12

https://msdn.microsoft.com/en-us/library/4wth1ha5.aspx

_CrtSetBreakAlloc

does that break after the nth allocation then?

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

13

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…