*** Leaked objects detected: 1 instance(s) of class TimerThread

[svenemtell]

We’re running Tracktion Engine as a Framework without GUI om macOS. When closing the app using the macOS Framework, we get a bunch of leaks, see below. We use RAII and no new or delete as far as I can see. When debugging it seems like the TimerThread has something to do with the settings file Settings.xml!?
Is it normal to get these leaked objects at program shutdown?
If not, any hints?
Thanks!

DLSSynth::deinitialise
DLSSynth::deinitialise
DLSSynth::~DLSSynth
DLSSynth::~DLSSynth
DLSSynth::~DLSSynth
DLSSynth::~DLSSynth
DLSSynth::~DLSSynth
closing MIDI output: Tracktion MIDI Device
Cleaning up temp files..
*** Leaked objects detected: 1 instance(s) of class TimerThread
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
*** Leaked objects detected: 1 instance(s) of class Thread
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
*** Leaked objects detected: 3 instance(s) of class WaitableEvent
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
*** Leaked objects detected: 1 instance(s) of class PropertiesFile
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
*** Leaked objects detected: 1 instance(s) of class PropertySet
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
*** Leaked objects detected: 8 instance(s) of class AudioBuffer
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
*** Leaked objects detected: 1 instance(s) of class BufferList
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
*** Leaked objects detected: 1 instance(s) of class OwnedArray
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
*** Leaked objects detected: 1 instance(s) of class SelectableUpdateTimer
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
*** Leaked objects detected: 3 instance(s) of class AsyncUpdater
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
*** Leaked objects detected: 1 instance(s) of class MessageManager
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
JUCE Assertion failure in juce_Singleton.h:50
JUCE Assertion failure in juce_Singleton.h:50
*** Leaked objects detected: 1 instance(s) of class StringPairArray
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
*** Leaked objects detected: 2 instance(s) of class StringArray
JUCE Assertion failure in juce_LeakedObjectDetector.h:92

[xenakios]

If you use static or global variables, the Juce memory leak detection may not correctly track those because that system itself depends on statics/globals.

[dave96]

The SelectableUpdateTimer at least should be juce::DeletedOnShutdown are you sure you’ve started juce correctly?

You can’t run Tracktion Engine without a full JUCE message loop as it needs the timers etc.

[railjonrogut]

Odd crash on M1 Mac (TimerThread)

Thanks for reporting this issue. Looking at the crash log, my best guess is that the timer thread is trying to lock MessageQueue::messages after the queue has already been destroyed. I’m not sure how that could be happening though… Are you calling stopTimer() in the destructors of all classes derived from Timer? Have you seen the same thing in any other JUCE plugins, such as the AudioPluginDemo? Is the plugin running as a native arm64 plugin, or emulated x86_64? I’ll have a go at reproducing …

Rail

[svenemtell]

This is how we start the Framework:

1. We create a juce::MessageManager by getting it from juce::MessageManager::getInstance()
2. We create a te::Engine

Is that correct and enough?

We tried running deleteInstance() on the juce::MessageManager at the end of our destructor, but we still get the leaks.

[dave96]

You need to wrap your main function in a ScopedJuceInitialiser_GUI init; like this:

Tracktion/tracktion_engine/blob/e84d2e6763608b63b30fb864e2ca150c28a0cbef/examples/TestRunner/TestRunner.h#L224

[svenemtell]

Great it works!
I notice the “GUI” in the name but I guess it isn’t a problem for a non-GUI app?
Thanks!

[dave96]

Yeah, I think it just sets up everything required for a GUI app.