OK, call me an idiot, but…

I had a app that was perfectly happy… then all the cool leak detection stuff came on. And it started to take a long time to shut down in the debugger. I’m almost certain it’s all shut-down stuff.

I got rid of 25% or so with an extra couple of deletedAtShutDown subclassings, but I still have a lot cropping up. A lot. And I left it alone, since it didn’t do any harm.

Well, it’s time. But I can’t seem to see where things start - the Xcode debugger hits in the subclasses, so I can’t tell exactly which of my classes is the problem.

Any tips on pinning it down? I think circular reference counted pointers may be involved as well - I’ve tried to explicitly stop and clear everything I can.



The order of destruction for objects with static storage duration is not well defined, so some of your leak messages may not be valid. In other words, you might be deleting your objects after the associated leak detector singleton (the object whose destructor Juce uses to check for leaks) is destroyed.

I talked about this at length in some of my other posts.


That rings a bell (got a link to your fix?)… but I’ve usually found it wiser to assume I’ve messed up, not Jules. I’m also trying to clean up, so ideally it would all be fully shut-down before juce itself shuts down. So any pointers to ID’ing what the leaked objects are?



I had a lot of trouble with this when I updated my Juce. I did manage to bumble into fixing it but I didn’t really come up with a good solution.

The simplest way is to just add Jules’ leak detector to your own classes. Eventually you find one of your own classes is leaking and you’re done.

The only other possibility is that you’re keeping Jules’ objects somewhere as lists of pointers that aren’t deleted - so Jules’ leak detector won’t detect your classes leaking, but when they are destroyed they drop all the pointers on the floor. That’s pretty easy to check for, and you should do that first!


That last case is what I suspect, but can’t tell which of my classes is the ‘keystone’ to the pyramid that gets dropped at the end. I’ll try adding LeakDetector class, thanks.



Bah, undef the LeakDetector stuff, run your code on Valgrind, you’ll get a useful error report instead of a slow bunch of useless memory dumps.


My solution was to implement my own singleton template, and my own leak detector (based on Juce) and coordinate the two classes together so that the leak detection always happens after all the singletons are destroyed.

In my framework, any objects with static storage duration must either be simple types, not use dynamic allocation, or be a singleton. This guarantees that the leak detection will always run after those objects are destroyed.


What the leakdetector stuff is great when you’re starting from a position where your app has no leaks. Then, when you’re writing code and you suddenly hit a leak, it’s usually pretty obvious what you just did that caused it, and having it there as a cheap safety-net to catch those mistakes is really useful.

But if you have an already-leaky app and try to use the leak detector class to fix it, well that’s not really what it’s good for! Best use a proper tool for that!


I wouldn’t say it’s a leaky app. It has no trouble in 24/7 situations with heavy use and a stable memory footprint. What it does have is a problem when it shuts down and the LeakDetector classes fire a lot. That dropped down quickly when I added DeleteAtShutdown, but a bunch of objects are still ‘leaked’. It’s actually irrelevant, since it only happens when the app is shutting down, but it would clearly mask a number of other ills.

I’m just looking for a way to identify which is the topmost instance of mine that triggers the detector, so I can work out it’s lifecycle, try to solve this. I think most of the others are probably owned or ref counted back from others.

Just seeing if anyone has clues or techniques.


I guess I wasn’t clear…

…what I was saying is that it is very likely that you don’t have any real leaks, its just that the leak detector destructor is getting called before the destructor for your object with static storage duration. See my previous post for how I solved it in my app.


I see. Well, I’m aiming to explicitly shut down most everything before the leakdetector would be destructed. I suppose there’s a few static members, but even those I’m trying to strip out first.

And your solution sounds like it will cover edge cases, and I suspect I’m still looking for more obvious culprits.