Singleton classes bug in DLL's?

I think there might be a problem with the Singleton Class code of JUCE when using it in a DLL. I have problems/crashes that are caused by AudioPluginFormatManager::getInstance(). These problems arise in Cubase SX 3, but only if Cubase once scanned my plugin (I think it creates and deletes it again).

I think the problem arises from the fact that the AudioPluginFormatManager inherits from DeletedAtShutdown. This works nicely for .exe’s, but DLL’s will stay in memory and so their static values are not set back to 0, because the DeletedAtShutdown’s deleteAll() will only delete the objects, but not call deleteInstance() of the Singleton Class code which sets the _singletonInstance variable back to 0.

So, next time the plugin gets loaded again, the _singletonInstance variable of the singleton code will still contain a non-0 value and you get a crash.

Agh… You’re catching some good bugs today! A singleton is supposed to call clearSingletonInstance() in its destructor, and it looks like I forgot to do so for that class. It should be:

AudioPluginFormatManager::~AudioPluginFormatManager() throw() { clearSingletonInstance(); }

I’ll get that sorted out right away.

I think that will not be enough.
In fact, the “alreadyInside” and “createdOnceAlready” variables will still be true, which will make bool problem become true in the getInstance() method.

…no, I don’t think so. alreadyInside is only used briefly, and always gets reset. And createdOnceAlready is only used if allowOnlyOneInstance is true, and in this case it isn’t.

Ok, true. But still allowOnlyOneInstance could be set back to false in the clearSingletonInstance() function to cover cases where the allowOnlyOneInstance parameter would indeed have been set to true!?

The whole point about allowOnlyOneInstance is that it stops you re-creating the singleton during a run. Resetting it would defeat the whole point. But I don’t think that flag would cause any problems in a plugin anyway, unless you’re using it in your own classes.