KnownPluginList isn't thread safe

#1

KnownPluginList isn’t thread safe. Scanning for plugins from a thread will call KnownPluginList::addType() which enters the typesArrayLock before modifying the list of types.

However, getNumTypes(), begin(), end(), and getType() that reads from the KnownPluginList don’t use the typesArrayLock. As well, the typesArrayLock is private so I can’t enter the lock myself.

So If I get a change message and then try and iterate over the KnownPluginList to see what’s up, then another plugin gets scanned as I’m still iterating, everything blows up.

6 Likes
#2

In the short term could you expose the typesArrayLock so I can work around it myself.

#3

Here is a minimal program that reproduces the problem: https://github.com/FigBug/juce_bugs/blob/master/ScanCrash/Source/MainComponent.cpp

I made a FakeScanner that is a subclass of KnownPluginList::CustomScanner and it returns a PluginDescription for whatever you give it. Then I just start making up possiblePluginFileOrIdentifier and scanning them as fast as I can. In the KnownPluginList changelistener, I iterate over the known descriptions, and then boom, it all blowns up within a few seconds.

#4

Thanks for the report and test program! I’ve pushed a change to the develop branch here which aims to address these issues. Instead of using the iterators or the getType()/getTypeFor..() methods (which were inherently thread unsafe) you should now call getTypes() which return a copy of the internal description array which you are free to manipulate how you please without having to worry about threading issues or pointers becoming invalid.

2 Likes
#5

Thanks. That looks like a pretty significant change, will take me a bit to get my main program updated. But I’ll give it a test with my sample program soon.