Site navigation

Juce Demo Memory Usage on El-Cap

MacOSX and iOS
#1

The Juce Demo seems to be leaking memory about 8mb/minute on El-Cap(10.11.6). This is with the welcome screen running.

My simple app that repaints 5 times a second leaks about 2mb/minute. If I bump the refresh to 50 times as second, I get about 8mb/minute.

Should I be worried, or is this normal?

Here’s the code for my repaint. Maybe I’m causing the leaking

void FretDisplayPaint::paint (Graphics& g)
{
g.fillAll (Colours::burlywood);

char text[100];
g.setFont (f);

for (int i=0;i<NUM_FRETS;i++)
{
    g.setColour (Colours::green);

    sprintf(text,"%2d:",i+1);
    float twidth = f.getStringWidth(String(text));

    g.drawText (text, slotpos(1,8) - twidth, (i+1) * vspacing - fontheight , twidth, vspacing, true);
}

for (int s=0;s<NUM_STRINGS;s++)
{
    for (int fret=0;fret<NUM_FRETS;fret++)
    {
        sprintf(text,"%6d",adcvals[s][fret]);
    float twidth = f.getStringWidth(String(text));

    if (notes[s][fret])
    {
        g.setColour (Colours::yellow);
        g.fillRect ( (float) slotpos(2+s,8) - getWidth()/9, (fret+1) * vspacing - .8*fontheight,(float) getWidth()/9, (float) fontheight);

    }

    g.setColour (Colours::green);

    g.drawText (text, slotpos(2+s,8) - twidth, (fret+1) * vspacing - fontheight , twidth, vspacing, true);
    }
}

}

#2

I’ve seen some leaking occur before related to fonts and multithreading. Also static fonts can cause some issues if I remember correctly. Where is variable f coming from? maybe try your example without setting the font, and then without any of the text drawing at all, does it make a difference?

#3

Seems that this is an Xcode related problem. If I run under Xcode, I see the leaking. Running standalone I don’t see much of a problem.

#4

What instrument are you using to detect these “leaks”?

We often get false alarms when people see the task manager’s memory use value for the process seem to rise, and don’t understand that it’s a very poor indicator of what’s really going on in the app.

Xcode’s instruments include awesome tools for memory debugging, and if you use them properly it’ll show you exactly what’s leaking (or more likely not leaking, since we’re pretty sure that nothing in the basic juce graphics system has a leak).

#5

That sounds reasonable. I’m using the basic performance monitor tab in the left frame. It matches the system activity monitor. I’ll know to use more advanced tools next time.

#6

If a process’ memory usage continues to rise without limit as long as it is running, it is almost certainly leaking.
Sometimes memory usage appears to grow for a few hours and then peaks, but if it continues to grow indefinitely without bounds there is almost certainly a leak. Xcode’s tools are good, but they are not foolproof and they can be turned off. If the leak occurs indirectly because of the way a library that JUCE wraps is being used (rather than directly as a result of allocation in JUCE itself) then Xcode’s tools will never detect it.

I refer you to this discussion from 2013: ComponentAnimator memory leak
In this discussion you initially made all these same points, then did some investigation and wrote:
“Ok… doing some digging, it seems that there’s an issue where the Images that ComponentAnimator uses are being deleted while the GL context is no longer active, which means their textures can’t be freed, and they get leaked. I’ll get on the case and sort this out…”

1 Like