TimerThread leaking

Hi everybody,
today I wrote a little command line tool, that loads an AudioProcessor.

These are the steps:

  • MessageManager::getInstance();
  • ScopedPointer<AudioProcessor> (using AudioProcessorValueTreeState)
  • after the AudioProcessor went out of scope: MessageManager::deleteInstance();

But after that it leaks a TimerThread, probably a result from the AudioProcessorValueTreeState:

*** Leaked objects detected: 1 instance(s) of class TimerThread
JUCE Assertion failure in juce_LeakedObjectDetector.h:88
*** Leaked objects detected: 1 instance(s) of class Thread
JUCE Assertion failure in juce_LeakedObjectDetector.h:88
*** Leaked objects detected: 3 instance(s) of class WaitableEvent
JUCE Assertion failure in juce_LeakedObjectDetector.h:88
*** Leaked objects detected: 1 instance(s) of class AsyncUpdater
JUCE Assertion failure in juce_LeakedObjectDetector.h:88

Has anybody an idea, how to get rid of that?
Thanks!

I also noticed this! Can it be made to work without the leak?

So here are the findings:

TimerThread is a raw pointer, but when deleting it is assumed it is a ScopedPointer:

Either change the instance into a ScopedPointer, use some kind of reference counting, or call delete…
You will know the best solution…

Cheers,
Daniel

1 Like

No, there’s no mistake in that code! It’s not intended to be a scoped pointer, and if you look again you’ll see that the object is already being deleted when it sets the pointer to null. That’s just to clear the singleton in case it gets used afterwards by mistake.

The TimerThread actually gets deleted by being a DeletedAtShutdown object. If for some reason the DeletedAtShutdown clearup method doesn’t get invoked, then it will leak, so you should try to see what’s interfering with the app’s overall shutdown sequence

1 Like

So that was the missing bit.

In my shutdown sequence I added

DeletedAtShutdown::deleteAll();
MessageManager::deleteInstance();

and the leak is gone. Thanks!

N.B. this is only, because I don’t use the JUCEApplication at all; it is an offline minimal command line tool reusing some structures, that are designed to be used in a JUCEApplication…

Ah, if it’s a command-line app with a main() function then you could do this with RAII using the ScopedJuceInitialiser_GUI class. It takes care of calling all the shutdown code for you.

1 Like

Awesome, that works like a charm.
Learned something today :slight_smile:

Thanks again!