It looks like there is an easy to reproduce memory leak related to Label::setText.
String newValue( "sometext" );
for (int k = 0; k < 1000000; ++k)
Label *test = new Label("foo", "bar");
test->setText( newValue, dontSendNotification ); // this apparently leaks
When running this code in a component, memory usage keeps rising very visibly while this code is running. This memory will never be freed. Remove “test->setText(…)” and all is fine. I observed this using VS 2013 and VS 2015, 64bit, standalone as well as plugin projects. JUCE 4.3 as well as 5.0. Repro works in a freshly set up project with nothing else in it.
Am I missing something here?
After a bit of investigation I found a nasty workaround to prevent this behavior:
in juce_Label.cpp, Label::setText, replace “textValue = newText;” with “textValue = Value(newText);”
This has been haunting me for a while. Any ideas/comments would be highly appreciated.
Nope, that’s not a leak.
Obviously memory will rise, because if you block the message thread and invoke millions of changes, then all those async change notification messages will be flooding the message thread. If you actually allowed the message loop to run again, they’ll be delivered and freed.
thanks for the quick reply.
After stepping through the code a bit more I came to a similar conclusion.
For some reason though it appears that the memory won’t get freed afterwards, and I can’t figure out why that is. So, all those messages apparently stick around forever. In this artificial test case, the listener is gone of course, but as far as I can tell this should be handled gracefully.
I’ll investigate a bit more. Thanks for pointing me in a promising direction
What makes you think the memory isn’t freed?
vs2015 debugger, realtime memory usage graph - hm, probably some internal buffers get enlarged and stay large? in that case I could stop investigating this
Just tried to reproduce this in the original real life scenario I once encountered (updating labels a lot with changing strings periodically, sometimes multiple times per frame). Since I could not reproduce any weird memory behavior I assume that whatever the original bug was that made me come up with that stupid test case is gone now. Thanks again for taking the time.