I’m working to create a Plugin Host, and for the most part all work as it should. But sometimes when I load or rescan plugins I face a crash in the JUCE_VST_WRAPPER_INVOKE_MAIN. For now it happen with Phoscyon demo plugin (windows 10 64bit) for example.
EDIT : The same problem occurs with the plugin host code provided in the juce example.
We tested on 2 computers on Windows, with one computer it sometimes works, and an other one it fails all the time.
EDIT 2 : After more tests, we discovered that two plugins are “incompatible”. When they are both scanned it crashes.
We isolated the scan on a new folder containing only these 2 plugins , plugin A and plugin B.
When we remove one of the 2 plugins, the scan runs fine.
However, when they are together in the folder, it crashes.
We tried on a 3rd computer with different plugins and it looks like there is a similar issue with different plugins.
I didn’t mean to imply any of that… but honestly, in my experience size doesn’t matter in bug-free-ness anyway…
Individual developer experience matters, but in bigger structures the culture towards development and QA plays a much bigger role. But that’s now very off-topic, sorry about that…
I hope we/you can find the reason, what’s going wrong, let us know…
These plugins are DLLs that are all being loaded into the host’s address space. Part of that process involves resolving DLL symbols by name, so if you have DLLs with the same symbol, they can often get linked to the wrong one. You can usually avoid problems by stripping all symbols in your release build but in debug builds or non-stripped release ones it’s just a fundamental hazard of the way DLLs work, I’m afraid!
Hello Daniel and Jules,
I work with Jonathan. @jules : we launched the exe directly outside visual studio (compiled in release mode) and removed the pdb files around the exe file. We have the same crash (we output the current plugin scanned in a log file)
“With Visual C++ (and other Microsoft compilers) on Windows, symbols aren’t part of the binaries. Instead, they are stored in separate files called “Program Database” files (.pdb files). Just don’t provide the .pdb files.”
@jules: I see, thanks for the clarification.
When we scan the 2 dlls separately , export the 2 plugins descriptions as xml files and merge these into a single pluginDescription xml file, then, we don’t have the issue anymore, and we are able to load them together using the KnownPluginList. What is the difference here?
I don’t really understand what you mean, but perhaps your problem is something other than the symbol name clash. I was just flagging that as a possible cause, since it does happen in this kind of situation.
To fill the KnownPluginList we can use the PluginDirectoryScanner or use an xml file. As the PluginDirectoryScanner does not crash when the two plugins aren’t load together, we can fill and export a KnownPluginList in xml and see the PluginDescription of both. We add merge the two xml, and load it in the KnownPluginList. And it works. Then we can create AudioPluginInstance of both plugins.
Maybe it’s more understandable with a sample of code :