VST Loading Crash: ModuleHandle::closeEffect()


#1

Hi Jules,

While playing around with the plugin host, I was trying to scan some plugins, and this free VST effect “triggered a breakpoint” in PluginHost (when attempting to close it): Combo.dll (from mda).
I’ve attempted debugging, but can’t seem to be able to figure out why since I’m not familiar enough with the VST code… so here’s a stack trace.

If I click “Continue” in VS, I can oddly still see the plugin in the list.
[attachment=0]mda Combo - The Crasher.png[/attachment]

Also, deleting an instance of this plugin when used as a filter causes a crash of the plugin host… at the same method call (juce::ModuleHandle::closeEffect(juce::AEffect * eff) Line 454).

This happens in Debug… and crashes the app when in release.


#2

Just a note; FL Studio and Audition scan/load/close it fine…


#3

Try the Release build of the plugin host, but without the debugger attached. Does it still crash?


#4

I tried it without the debugger attached in the first place, so yep.


#5

Upon a further attempt of understanding the VST code while walking through this issue; it seems to be related to the plugin itself… Although such wouldn’t explain why the DAWs I have at hand can load, use and close this plugin fine.


#6

There are many plugins out there that are written with dodgy assumptions about the exact order or timing with which their functions will be called, so they end up working ok in the host that they were written for, but get fragile when other hosts deviate slightly from that behaviour.

The juce host wrapper definitely doesn’t do anything silly or unreasonable, so I think that the tiny number of plugins that still fail are probably just a bit flakey. Unfortunately to attempt to guess what it is that they don’t like, and to change the wrapper to accommodate that is almost impossible without being able to debug them.


#7

In the back of my mind, I knew that that was the cause…

Fair enough!

Thanks for clarifying, Jules!


#8

Could be worth telling the plugin’s developer though - it’s much easier for them to debug it than for us to try to guess what’s wrong.


#9

Yeah, good call


#10

Hey Jules,

I got in touch with the developer of the MDA plugins (Paul Kellett) - he looked into it rather speedily! Here’s his reply to my e-mail letting him know that his plugin somehow crashes the plugin host:

Paul is referring to the following method: juce::VSTPluginInstance::getVersion().

I did a bit of research and came across the following in the VST code’s documentation (see aeffect.h - line 180):

struct AEffect
{
//[...] code before here
	VstInt32 version;		///< plug-in version (example 1100 for version 1.1.0.0)
 //[...] more code after
}

#11

Ah… That’s a bit awkward then…

All juce-based plugins will use base 16 to build the version number; if other ones are using base 10, then that makes it things a bit tricky. If I change the host to use base 10, all the juce ones will look wrong. Hmm. Yeah. Not sure about that…


#12

Well I think the Juce VST host is one of the few hosts that actually show the VST version number. FL Studio and Audtion don’t ever show it. Also I’m guessing most people were probably using a text label to put there version number in their plugin rather than using the code based plugin version number directly. This is probably why it has gone unnoticed all these years.

If all other hosts are following the VST spec properly and using base 10, then all the juce based vst plugins are showing to wrong version in all those hosts. Additionally since it is causing the juce host to crash, this is definitely a bug that should be fixed on the plugin and host side.


#13

Hmm. Yes, I guess I’ll just have to change both the host and plugin classes. Damn.


#14

I see your changes for this - cool!

I also see that you changed the juce_AudioPluginModule file to use the decimal format instead of hex… that may not be good since AU plugins utilize base-16 for version numbers (see the Audio Unit Identification section)…


#15

Oh, ffs… Yes, thanks for the heads-up.


#16

Yep, no worries. (Not sure how this will affect RTAS and AAX though…)


#17

I’ve re-done it now, so the number stays in hex, and only gets converted to decimal for VST.


#18

Alrighty - thanks Jules. :slight_smile:


#19

Ah dang - there’s another instance of JucePlugin_VersionCode used in the VST wrapper that should be converted to decimal as well…

    VstInt32 getVendorVersion()         { return JucePlugin_VersionCode; }

#20

Drat! Easily fixed though, thanks!