VST3 crashes Samplitude X2 on unload

Just got a report from a beta tester about a hard VST3 crash in Samplitude.

When unloading our plug-in in Samplitude X2, Samplitude will crash hard without an error message.

When using the debugger, it appears that there are 120 leaked instances of “CachedGlyphEdgeTable”. Any idea what could be causing this? I’ve tested this with the JUCE demo plug-ins and they crash as well (not just our plug-ins).

120 leaked instances of "CachedGlyphEdgeTable"
1 leaked instance of "GlyphCache"
1 leaked instance of "OwnedArray"
1 leaked instance of "TimerThread"
1 leaked instance of "Thread"
1 leaked instance of "JuceAudioProcessor"
1 leaked instance of “JuceVST3Component”

Many more leaks. It appears that nothing is getting deleted properly.

Just to clarify: 64-bit VST3 on Windows Samplitude X2. Our tester uses Windows 7, and I’m on Windows 10.

Bumping this for the weekday.

Could we get an official response? We are hoping to launch our new plug-in in two weeks and this is blocking release.

We’ve seen your post and we are investigating.

Great, thank you!

Sorry for the late reply. I’ve tried re-producing this with various in-house plug-ins and I only get assertions in the LeakDetector. This is because Samplitude X2 will simply unload the dll without properly calling the destructors of the VST3 components. That’s fine, as Samplitude will shutdown anyway, so any leaked memory will be freed a few moments later. However, it does, of course, invoke the LeakDetector.

Building our in-house plug-ins (and the JuceDemoPlugin) in Release mode (disables assertions) gets rid of the breakpoint and all plug-ins seem to work as expected.

Could you send us a stack trace of your plug-in running in release mode with assertions turned off?

Hi Fabian,

The issue isn’t occurring when Samplitude shuts down, but rather when the plugin is removed from the track. We’re experiencing a hard crash (immediate shut down with no error notification) when this happens, so we can’t even get a stack trace. It’s occurring in debug and release modes.

Can you run Samplitude in the debugger? Does the debugger break?

Unfortunately, my Samplitude trial expired, so I’ll have to e-mail them to extend my license.

Are you not able to reproduce the crash? It’s happening in our plug-ins and the JUCE demo plug-ins. Our beta tester reported that Lindell plug-ins are exhibiting the same behavior, and I believe that they’re using JUCE.

Any updates on this?

I tried reproducing it but I only get leaked memory objects when samplitiude quits (which is expected and will only occur in a debug build). I was actually waiting for you to run your plug-in in the debugger. Any update on this?