Assert on Timer Singleton creation when instantiating my plugin a second time

Audio Plugins
1

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 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.

2

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?

3

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

4

@anthony-nicholls
This sounds exactly like this issue on the JUCE git:

You said, on May 15th,2024:

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.

1 Like
5

@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 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.

1 Like
6

@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.

1 Like