VSTSDK 3.6.12 AGain Crashes Samplitude Pro X3 Suite

Hi all,

This post is related to Will Pirkle’s topic about the behavior of AGain here:

This topic is intended to cover the behavior of various hosts with AGain from VSTSDK 3.6.12, in particular my findings for hosts other than those mentioned by Will.

Using VSTSDK 3.6.12 I have managed to crash Samplitude Pro X3 Suite with multiple instantiations of AGain and the VS 2017 debugger attached to the Samplitude process. Samplitude is, compared to Waveform 9, Mixcraft 8 Pro Studio, and VSTHost by Hermann Seib, significantly more difficult to crash. However, by recording multiple automations of the Gain slider for several (say three or four) instantiations of AGain, then moving the slider about wildly through rapid gesticulations for an additional instantiation, I was able to cause Samplitude to crash in two different modes (see call stacks below). The most common crash was the first listed below, but this particular type of crash could be eliminated by commenting out both of the lines containing CTextEdit in the file again.uidesc, whereas the second type of crash was not impacted by this change.

A common symptom is shown by looking at line 1926 of cframe.cpp. Often the “end” rectangle is bad — its coordinates are left = -1.45e+144 with the same numbers for the others (right, top, bottom). This suggests to me that a rectangle is being deleted by another function, but it should not be, or it should have changed “end” but has not done so. Perhaps this behavior is expected, but I wanted to mention it anyway. Usually the coordinates are reasonable FP values.

I also tested Cubase Elements 10 version 10.0.10 (the most recent update as of December 2018) with multiple instantiations, but I found it impossible to crash so far. I used as many as five instantiations with automation recording of the Gain slider plus a sixth instantiation which I manipulated manually. Interestingly, Cubase slowed down the frame rate of the animations for the automation recordings so that it appeared that the slider was moving very slowly, but the animation for the manually manipulated one followed my movements at a much faster frame rate. The audio seemed to follow the rapid movements of all Gain sliders as I had manipulated and recorded them, but the audio and the animation were completely out of sync — no correlation whatsoever.

Reaper version 5.965 was also impossible to crash so far, even with five instantiations with automation recording and one slider moved about manually. The difference between Cubase Elements 10 and Reaper 5.965 was that Reaper did not slow down the frame rate of the five automation recordings. All the Gain sliders appeared to be moving in concert with the recorded movements and with the audio, as far as I could tell.

Although the behavior of the last two hosts is encouraging, the behavior of the other four other hosts is worrisome. The problem may very well be within VST 3 SDK or VSTGUI, but it is also host-related somehow.

To review the findings with all the various hosts: It was quite easy, almost trivial, to crash Waveform 9, Mixcraft 8 Pro Studio, and VSTHost (Seib) with only one instantiation of the AGain example plugin from VSTSDK 3.6.12 by moving the Gain slider wildly about. In some cases, the host would crash in the manner described by Will with my merely opening or closing the window for the plugin, or by moving the mouse inside the plugin. Usually crashing required moving the Gain slider about wildly. With Samplitude Pro X3 Suite, crashing required much more activity which I created by using automation recording. After wildly moving Gain sliders were recorded, it was fairly easy to crash Samplitude with VS 2017 running a debugger attached to Samplitude. Cubase Elements 10.0.10 and Reaper 5.965 have not crashed so far, even with using lots of automation recording to increase the activity of the meters and the Gain slider. Removing lines involving CTextEdit from the file again.uidesc reduces the incidence of crashing, but does not eliminate it.

I should also mention that while testing the VSTSDK 3.6.9 version of AGain under that SDK, I saw the following message in the output window of a crash of Samplitude Pro X3 Suite running AGain, a message which Will tells me is from the win32frame.cpp file from VSTGUI4:

“This sometimes happens, only when we are currently processing a mouse down event and via a callback into the host the window gets destroyed. Otherwise this should never get called. We are the owner of the window and we are responsible of destroying it.”

Given that I found the crashing behaviors of the hosts identical with both VSTSDK 3.6.9 and VSTSDK 3.6.12, I conclude that this message probably would eventually be issued in the output window of a crash using VSTSDK 3.6.12.


Call stack for VST SDK 3.6.12 AGain running under Samplitude Pro X3 Suite x64:

Most common crash (perhaps 80% of them). This crash was eliminated by commenting out both lines containing CTextEdit in the file again.uidesc :

vcruntime140d.dll!00007fffdd757020() Unknown
vcruntime140d.dll!00007fffdd756713() Unknown
vcruntime140d.dll!00007fffdd7572b3() Unknown

again.vst3!VSTGUI::D2DFont::createTextLayout(VSTGUI::IPlatformString * string) Line 98 C++
again.vst3!VSTGUI::D2DFont::getStringWidth(VSTGUI::CDrawContext * context, VSTGUI::IPlatformString * string, bool antialias) Line 152 C++
again.vst3!VSTGUI::CDrawContext::drawString(VSTGUI::IPlatformString * string, const VSTGUI::CRect & rect, const VSTGUI::CHoriTxtAlign hAlign, bool antialias) Line 254 C++
again.vst3!VSTGUI::CParamDisplay::drawPlatformText(VSTGUI::CDrawContext * pContext, VSTGUI::IPlatformString * string, const VSTGUI::CRect & size) Line 363 C++
again.vst3!VSTGUI::CParamDisplay::drawPlatformText(VSTGUI::CDrawContext * pContext, VSTGUI::IPlatformString * string) Line 328 C++
again.vst3!VSTGUI::CTextLabel::draw(VSTGUI::CDrawContext * pContext) Line 119 C++ again.vst3!VSTGUI::CTextEdit::draw(VSTGUI::CDrawContext * pContext) Line 203 C++
again.vst3!VSTGUI::CView::drawRect(VSTGUI::CDrawContext * pContext, const VSTGUI::CRect & updateRect) Line 65 C++
again.vst3!VSTGUI::CViewContainer::drawRect(VSTGUI::CDrawContext * pContext, const VSTGUI::CRect & updateRect) Line 884 C++
again.vst3!VSTGUI::CViewContainer::drawRect(VSTGUI::CDrawContext * pContext, const VSTGUI::CRect & updateRect) Line 884 C++
again.vst3!VSTGUI::CFrame::drawRect(VSTGUI::CDrawContext * pContext, const VSTGUI::CRect & updateRect) Line 338 C++
again.vst3!VSTGUI::CFrame::platformDrawRect(VSTGUI::CDrawContext * context, const VSTGUI::CRect & rect) Line 1583 C++
again.vst3!VSTGUI::Win32Frame::paint(HWND
_ * hwnd) Line 593 C++
again.vst3!VSTGUI::Win32Frame::proc(HWND__ * hwnd, unsigned int message, unsigned __int64 wParam, int64 lParam) Line 748 C++
again.vst3!VSTGUI::Win32Frame::WindowProc(HWND
* hwnd, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 961 C++
[External Code]

Output Window not captured.


addRect type of crash. This crash was NOT eliminated by commenting out both of the lines containing CTextEdit in the file again.uidesc:

ucrtbased.dll!00007fffc351afac() Unknown
ucrtbased.dll!00007fffc351aef7() Unknown

again.vst3!std::_Vector_const_iterator<std::_Vector_val<std::_Simple_typesVSTGUI::CRect > >::_Compat(const std::_Vector_const_iterator<std::_Vector_val<std::_Simple_typesVSTGUI::CRect > > & _Right) Line 199 C++
again.vst3!std::_Vector_const_iterator<std::_Vector_val<std::_Simple_typesVSTGUI::CRect > >::operator==(const std::_Vector_const_iterator<std::_Vector_val<std::_Simple_typesVSTGUI::CRect > > & _Right) Line 165 C++
again.vst3!std::_Vector_const_iterator<std::_Vector_val<std::_Simple_typesVSTGUI::CRect > >::operator!=(const std::_Vector_const_iterator<std::_Vector_val<std::_Simple_typesVSTGUI::CRect > > & _Right) Line 170 C++
again.vst3!VSTGUI::CFrame::CollectInvalidRects::addRect(const VSTGUI::CRect & rect) Line 1909 C++
again.vst3!VSTGUI::CFrame::invalidRect(const VSTGUI::CRect & rect) Line 1411 C++
again.vst3!VSTGUI::CViewContainer::invalidRect(const VSTGUI::CRect & rect) Line 753 C++
again.vst3!VSTGUI::CView::invalidRect(const VSTGUI::CRect & rect) Line 560 C++
again.vst3!VSTGUI::CView::invalid() Line 78 C++
again.vst3!VSTGUI::ParameterChangeListener::updateControlValue(double value) Line 308 C++
again.vst3!VSTGUI::ParameterChangeListener::update(Steinberg::FUnknown * changedUnknown, long message) Line 177 C++
again.vst3!Steinberg::UpdateHandler::doTriggerUpdates(Steinberg::FUnknown * u, long message, bool suppressUpdateDone) Line 416 C++
again.vst3!Steinberg::UpdateHandler::triggerUpdates(Steinberg::FUnknown * u, long message) Line 441 C++
again.vst3!Steinberg::FObject::changed(long msg) Line 110 C++
again.vst3!Steinberg::Vst::Parameter::setNormalized(double normValue) Line 101 C++
again.vst3!Steinberg::Vst::EditController::setParamNormalized(unsigned long tag, double value) Line 186 C++
again.vst3!Steinberg::Vst::AGainController::setParamNormalized(unsigned long tag, double value) Line 308 C++
[External Code]

Output Window:

c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.16.27023\include\vector(199) : Assertion failed: vector iterators incompatible
Unhandled exception at 0x00007FFFC351AFAC (ucrtbased.dll) in Sam_x64.exe: An invalid parameter was passed to a function that considers invalid parameters fatal.

Regards,
Dave Clark

We have a user report that our VST3SDK plugin crashes in Samplitude X3 and I confirmed the issue with X6.
Since our plugin shows no errors in the validator and runs fine in Ableton, Bitwig, Ardour, Reaper, etc., I think it is reasonable to assume the issue is with Samplitude.