I am evaluating a demo copy of JUCE 4.2. for use in my application.
I am evaluating on OS X El Capitan. I seem to be seeing constant memory footprint
growth (probably memory leakage, but possibly other causes) on any app that does
animation. In fact, the simple AnimationAppExample included with JUCE grows at about
8 Mb per hour on my system.
Is this a known issue? Any solutions?
Screenshots from activity monitor taken at about 830PM, then again at 10:00PM attached …
Series of screenshots … initially AnimationAppExample uses 12.5 Mb of memory. After about 2 hours the memory usage (more than) doubles to 26.3 Mb, and after 7 hours it quadruples to 50.2 Mb. Memory use is growing at a constant rate in this simple JUCE example program you provide. This is almost certainly a memory leak.
Startup:
After 2 hours or so:
After 8 hours:
I had a look at this and I can’t see anything obviously wrong. Xcode’s leak checker doesn’t report any useful information either.
This might be very hard to track down…
I’d be very surprised if you’re seeing a memory leak in the way most people would understand that term - i.e. our code leaving an object on the heap or failing to deallocate a system resource. If we did that, it’d show up in the Xcode memory debugger.
Could be a symptom of heap fragmentation, or CoreGraphics internally increasing its cache size in a way that’s beyond our control. Perhaps there’s a CoreGraphics analyser that we could run on it?
Also @t0m, might be worth trying it with the software or openGL renderer to see if that makes a difference.
Here’s ONE leak found in your code that wasn’t being caught by the Xcode tools. Apparently the xcode memory tools don’t work that well for Objective-C.
juce_mac_MouseCursor.mm, near line 60
static void* fromHIServices (const char* filename)
{
...
near line 69:
NSImage* originalImage = [[NSImage alloc] initByReferencingFile: juceStringToNS(cursorPath + “/cursor.pdf”)];
…
around line 95:
[originalImage release]; // <- ADD THIS LINE TO PLUG YOUR LEAK
…
}
You’re welcome.
Unfortunately that’s not the big one,
but maybe take a closer look at the layer that is written in Objective-C?
@jules along with dropping C++98 support, here’s an argument for making JUCE 5 Obj-C code utilize ARC. macOS 10.7+ and iOS 5+ would be required, but almost everything else nowadays requires at least these OSes.
ARC doesn’t help you that much when you mix ObjC with C/C++ unfortunately.
The animation app leak was found in 4.2, but the leak I posted was found in
the JUCE
version that’s bundled with Helm, so it could well be an earlier version.
More details later, it’s 6AM here.
I see the same behaviour on the develop tip with both Core Graphics and the software renderer. So that’s one thing (probably) ruled out.
OK, definitive answer is JUCE 4.2.3 for both versions. I see you are now on 4.3 so it’s a little behind. I assume you found & fixed the leak posted above in between those versions.
It’s quite possible that we are talking about “abandoned memory” (rather than a “leak”) here, although I have always considered those two terms to mean the same thing. If I were chasing this any further my next step would be to would use the techniques described here: https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/FindingAbandonedMemory.html
