# Assert on Timer Singleton creation when instantiating my plugin a second time **URL:** \ **Category:** Audio Plugins\ **Created:** [November 13, 2024, 7:10am UTC](https://forum.juce.com/t/assert-on-timer-singleton-creation-when-instantiating-my-plugin-a-second-time/64197 "2024-11-13T07:10:53Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![stephenk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/stephenk/32/15198_2.png) [@stephenk](https://forum.juce.com/u/stephenk)\ **Post date:** [November 13, 2024, 7:10am UTC](https://forum.juce.com/t/assert-on-timer-singleton-creation-when-instantiating-my-plugin-a-second-time/64197/1 "2024-11-13T07:10:53Z")
I’ve just noticed this issue, which seems to have crept into my plugin somewhere between 7.0.9 (?) and now (8.0.3), because I haven’t tested this specifically recently: When I instantiate my plugin (which uses a number of standard Timers) in the AudioPluginHost, then delete the plugin, and then instantiate it a second time, I hit an assert in juce\_Singleton.h line 74. ```auto auto once = onlyCreateOncePerRun; // (local copy avoids VS compiler warning about this being constant) if (once) { static bool createdOnceAlready = false; if (createdOnceAlready) { // This means that the doNotRecreateAfterDeletion flag was set // and you tried to create the singleton more than once. jassertfalse; return nullptr; } createdOnceAlready = true; } ``` It hits the assert during the second creation when calling startTimer() on a standard Timer that is part of a class that inherits it - nothing fancy or custom about it. It seems that the Timer Thread is still running when it shouldn’t be? I didn’t shut it down properly somehow? I’m not sure I understand this… What could I be doing (or missing) during the deletion of my plugin that causes this issue? (And I never used to hit this…) I don’t mess with threads at all in my project. I just use a number of standard Timers and make sure to Stop them before deletion. Was something changed with the Singleton implementation during that time? Thanks for any ideas. ---
**Author:** ![ibisum](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ibisum/32/21288_2.png) [@ibisum](https://forum.juce.com/u/ibisum)\ **Post date:** [November 13, 2024, 9:57am UTC](https://forum.juce.com/t/assert-on-timer-singleton-creation-when-instantiating-my-plugin-a-second-time/64197/2 "2024-11-13T09:57:04Z")
Perhaps the Timer destructors’ are not being called because the Timer is encapsulated in a class which as also not been deconstructed yet? Are you calling stopTimer() in the right place - i.e. in destructors? ---
**Author:** ![kunz](https://avatars.discourse-cdn.com/v4/letter/k/f19dbf/32.png) [@kunz](https://forum.juce.com/u/kunz)\ **Post date:** [November 13, 2024, 12:41pm UTC](https://forum.juce.com/t/assert-on-timer-singleton-creation-when-instantiating-my-plugin-a-second-time/64197/3 "2024-11-13T12:41:12Z")
The timer should stop itself when deconstruction happens. I don’t think this is the problem. I wasn’t able to reproduce the assert, also when I didn’t stop the timer. Are you creating the object that contains the timer on the main thread? Because it is a singleton, it’s shared with other plugin instances. This can lead to all kinds of issues. Edit: Another option would be a memory leak on your side. Are you sure the deconstructor of your class that inherits from Timer is called when you remove the plugin? Edit: Tested with 8.0.3 on macOS ---
**Author:** ![stephenk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/stephenk/32/15198_2.png) [@stephenk](https://forum.juce.com/u/stephenk)\ **Post date:** [November 13, 2024, 7:11pm UTC](https://forum.juce.com/t/assert-on-timer-singleton-creation-when-instantiating-my-plugin-a-second-time/64197/4 "2024-11-13T19:11:18Z")
@anthony-nicholls This sounds exactly like this issue on the JUCE git: > > > \### Detailed steps on how to reproduce the bug > > In any DAW, insert \`AudioPlugi…nDemo\` on a track. Then close the project, start a new one, and once again insert \`AudioPluginDemo\`. Get an assertion failure due unexpected recreation of the \`TimerThread\` singleton. > > Tested on current develop branch tip bbc63ba151265d9199b5d1cfd3f70fb24442563f (which also seems like the regressing commit) > > \### What is the expected behaviour? > > No assertion failure > > \### Operating systems > > macOS > > \### What versions of the operating systems? > > \- > > \### Architectures > > 64-bit > > \### Stacktrace > > \`\`\`shell > \#0 0x00000001384de7d0 in juce::SingletonHolder\::get() at /Users/dan/dev/JUCE\_vanilla/JUCE/modules/juce\_core/memory/juce\_Singleton.h:74 > \#1 0x00000001384d38f0 in juce::Timer::TimerThread::getInstance() at /Users/dan/dev/JUCE\_vanilla/JUCE/modules/juce\_events/timers/juce\_Timer.cpp:32 > \#2 0x00000001384d3460 in juce::Timer::startTimer(int) at /Users/dan/dev/JUCE\_vanilla/JUCE/modules/juce\_events/timers/juce\_Timer.cpp:306 > \#3 0x00000001384d3c80 in juce::Timer::startTimerHz(int) at /Users/dan/dev/JUCE\_vanilla/JUCE/modules/juce\_events/timers/juce\_Timer.cpp:321 > \#5 0x0000000138295544 in juce::AudioProcessorValueTreeState::AudioProcessorValueTreeState(juce::AudioProcessor&, juce::UndoManager\*) at /Users/dan/dev/JUCE\_vanilla/JUCE/modules/juce\_audio\_processors/utilities/juce\_AudioProcessorValueTreeState.cpp:264 > \#4 0x00000001382950f4 in juce::AudioProcessorValueTreeState::AudioProcessorValueTreeState(juce::AudioProcessor&, juce::UndoManager\*) at /Users/dan/dev/JUCE\_vanilla/JUCE/modules/juce\_audio\_processors/utilities/juce\_AudioProcessorValueTreeState.cpp:265 > \#6 0x00000001382953f8 in juce::AudioProcessorValueTreeState::AudioProcessorValueTreeState(juce::AudioProcessor&, juce::UndoManager\*, juce::Identifier const&, juce::AudioProcessorValueTreeState::ParameterLayout) at /Users/dan/dev/JUCE\_vanilla/JUCE/modules/juce\_audio\_processors/utilities/juce\_AudioProcessorValueTreeState.cpp:209 > \#7 0x00000001380d8070 in JuceDemoPluginAudioProcessor::JuceDemoPluginAudioProcessor() at /Users/dan/dev/JUCE\_vanilla/AudioPluginDemo/AudioPluginDemo/Source/AudioPluginDemo.h:184 > \#8 0x00000001380d7ed0 in JuceDemoPluginAudioProcessor::JuceDemoPluginAudioProcessor() at /Users/dan/dev/JUCE\_vanilla/AudioPluginDemo/AudioPluginDemo/Source/AudioPluginDemo.h:187 > \#9 0x00000001380d7e7c in createPluginFilter() at /Users/dan/dev/JUCE\_vanilla/AudioPluginDemo/AudioPluginDemo/Source/Main.cpp:15 > \#10 0x00000001380555e0 in juce::createPluginFilterOfType(juce::AudioProcessor::WrapperType) at /Users/dan/dev/JUCE\_vanilla/JUCE/modules/juce\_audio\_plugin\_client/detail/juce\_CreatePluginFilter.h:35 > \#11 0x000000013805522c in juce::JuceVST3Component::JuceVST3Component(Steinberg::Vst::IHostApplication\*) at /Users/dan/dev/JUCE\_vanilla/JUCE/modules/juce\_audio\_plugin\_client/juce\_audio\_plugin\_client\_VST3.cpp:2436 > \#12 0x0000000138055140 in juce::JuceVST3Component::JuceVST3Component(Steinberg::Vst::IHostApplication\*) at /Users/dan/dev/JUCE\_vanilla/JUCE/modules/juce\_audio\_plugin\_client/juce\_audio\_plugin\_client\_VST3.cpp:2438 > \#13 0x00000001380550b8 in juce::JucePluginFactory::getClassEntries()::'lambda'(Steinberg::Vst::IHostApplication\*)::operator()(Steinberg::Vst::IHostApplication\*) const at /Users/dan/dev/JUCE\_vanilla/JUCE/modules/juce\_audio\_plugin\_client/juce\_audio\_plugin\_client\_VST3.cpp:4244 > \#14 0x0000000138055084 in juce::JucePluginFactory::getClassEntries()::'lambda'(Steinberg::Vst::IHostApplication\*)::\_\_invoke(Steinberg::Vst::IHostApplication\*) at /Users/dan/dev/JUCE\_vanilla/JUCE/modules/juce\_audio\_plugin\_client/juce\_audio\_plugin\_client\_VST3.cpp:4242 > \#15 0x000000013805359c in juce::JucePluginFactory::createInstance(char const\*, char const\*, void\*\*) at /Users/dan/dev/JUCE\_vanilla/JUCE/modules/juce\_audio\_plugin\_client/juce\_audio\_plugin\_client\_VST3.cpp:4130 > \#16 0x0000000100527f60 in VST\_HostedPlugin::VST3\_Init(int, char const\*, WDL\_FastString\*) () > \#17 0x00000001003609b4 in VST\_HostedPlugin::OpenFromUID(char const\*, int, char const\*, WDL\_FastString\*, bool, int) () > \#18 0x0000000100378624 in FxDsp::FxDsp(int, char const\*, char const\*, void\*, int) () > \#19 0x00000001003a87dc in FxChain::addDspToChain(int, char const\*, char const\*, void\*, int, bool) () > \#20 0x00000001003c7558 in fxadd\_add\_recs\_to\_chain(FxAddDef\*\*, int, FxChain\*, int, int, int, bool, bool) () > \#21 0x00000001003d6c94 in add\_to\_chain(HWND\_\_\*, FxChain\*, int, int, int, bool, int, bool) () > \#22 0x00000001003d64dc in do\_insert(HWND\_\_\*, bool) () > \#23 0x00000001003cb748 in addDialogProc(HWND\_\_\*, unsigned int, unsigned long, long) () > \#24 0x00000001004cff8c in SwellDialogDefaultWindowProc(HWND\_\_\*, unsigned int, unsigned long, long) () > \#25 0x00000001003cb2e4 in addDialogProc(HWND\_\_\*, unsigned int, unsigned long, long) () > \#26 0x00000001004cff8c in SwellDialogDefaultWindowProc(HWND\_\_\*, unsigned int, unsigned long, long) () > \#27 0x00000001004ce334 in -\[REAPERSwell\_hwnd swellOnControlDoubleClick:\] () > \#28 0x000000018bebdc70 in -\[NSApplication(NSResponder) sendAction:to:from:\] () > \#29 0x000000018bebda74 in -\[NSControl sendAction:to:\] () > \#30 0x000000018bfbee5c in -\[NSTableView \_sendAction:to:row:column:\] () > \#31 0x000000018bfbd698 in -\[NSTableView mouseDown:\] () > \#32 0x00000001004eafc8 in -\[REAPERSwell\_listview mouseUp:\] () > \#33 0x000000018c851834 in \_routeMouseUpEvent () > \#34 0x000000018be43f8c in -\[NSWindow(NSEventRouting) \_reallySendEvent:isDelayedEvent:\] () > \#35 0x000000018be43c38 in -\[NSWindow(NSEventRouting) sendEvent:\] () > \#36 0x000000018c509e70 in -\[NSApplication(NSEventRouting) sendEvent:\] () > \#37 0x0000000100334140 in -\[REAPERapp sendEvent:\] () > \#38 0x000000018c1578cc in -\[NSApplication \_handleEvent:\] () > \#39 0x000000018bd0bcdc in -\[NSApplication run\] () > \#40 0x000000018bce2f54 in NSApplicationMain () > \#41 0x000000018805a0e0 in start () > \`\`\` > > > \### Plug-in formats (if applicable) > > \_No response\_ > > \### Plug-in host applications (DAWs) (if applicable) > > Tested on REAPER but probably any DAW > > \### Testing on the \`develop\` branch > > The bug is present on the \`develop\` branch > > \### Code of Conduct > > \- \[X\] I agree to follow the Code of Conduct You said, on May 15th,2024: > [@](#): > > Thanks for reporting [@danra](https://github.com/danra) we’re aware of this issue, a number of us are out of the office at the moment we’ll get back to this as soon as possible. I have now compiled my last working JUCE 7 version on JUCE 7.0.9 - no problem. Then I compile it on JUCE 7.0.12 - PROBLEM. And I still have the problem in my current JUCE 8.0.3 project. So it appears there’s no difference in my code that is causing it, but rather something in JUCE between JUCE 7.0.10 and 12 (I never downloaded .10 and .11). Am I experiencing the same issue and is anything going on with it? Thanks. ---
**Author:** ![anthony-nicholls](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/anthony-nicholls/32/1246_2.png) [@anthony-nicholls](https://forum.juce.com/u/anthony-nicholls)\ **Post date:** [November 18, 2024, 1:55pm UTC](https://forum.juce.com/t/assert-on-timer-singleton-creation-when-instantiating-my-plugin-a-second-time/64197/5 "2024-11-18T13:55:55Z")
@stephenk although such a bug did exist at some point it shouldn’t be present in JUCE 8, I believe the issue is addressed by [this](https://github.com/juce-framework/JUCE/commit/69ddb29d739183f73dadf2d257953891092fd68d) commit. I also can’t reproduce the issue. If you are seeing it on JUCE 8 could you please share a simple example that reproduces the issue and let us know which platform/host you’re testing with. Thanks. ---
**Author:** ![stephenk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/stephenk/32/15198_2.png) [@stephenk](https://forum.juce.com/u/stephenk)\ **Post date:** [November 20, 2024, 6:30am UTC](https://forum.juce.com/t/assert-on-timer-singleton-creation-when-instantiating-my-plugin-a-second-time/64197/6 "2024-11-20T06:30:58Z")
@anthony-nicholls Thanks so much for the reply. I think I may have been mixing some plugins I compiled with JUCE 7 with some others I compiled with JUCE 8, because I am no longer seeing the issue in JUCE 8 with everything freshly compiled. Sorry for any confusion.