VST3 A/B Crash

I’ve just come across a VST3 crash in Cubase 9.0.1 on Mac when using the host A/B button.

The crash is happening on line 1326 of juce_VST3_Wrapper.cpp, while calling htonl(), after the second time of clicking the A/B button.

This is affecting the tip of Develop, and it seems to have been working fine in Cubase 8.5.10!

Has anyone else come across this and managed to find a fix?

You need to find out whether this is a bug in your own code before we can investigate - have you tried this with any of the juce demo plugins?

Yes, I’ve seen this with the Juce Demo Plugin on the develop branch.

1 Like

FYI, I’m also seeing the same crash when using the Copy Setting / Paste Setting options in the plug-in menu (using VST3 in Cubase 9).

I have also just seen the original crash in Cubase 8.5, but I was clicking the A/B button repeatedly and fast…

Just tested this on OS X and Windows with Cubase 9.0.10 Build 150 (latest update of today). And I can’t reproduce this.

I’ve just made sure I’m on the same build (Cubase 9.0.10 Build 150, on OS X 10.12.2), and pulled Develop, and still hit the same problem with the Juce Demo Plugin:

Process: Cubase 9 [3441]
Path: /Applications/Cubase 9.app/Contents/MacOS/Cubase 9
Identifier: com.steinberg.cubase9
Version: (
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Cubase 9 [3441]
User ID: 502

Date/Time: 2017-02-27 14:16:02.938 +0000
OS Version: Mac OS X 10.12.2 (16C67)
Report Version: 12
Anonymous UUID: 5359CA1D-4E4A-8EA3-2E15-1DF1F26C7EEF

Sleep/Wake UUID: E9AB4096-F977-4F7E-AF2B-FA37A038DD91

Time Awake Since Boot: 18000 seconds
Time Since Wake: 920 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Codes: EXC_I386_GPFLT

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.juce.JuceDemoPlugin 0x0000000137da8582 juce::JuceVST3Component::loadVST2CompatibleState(char const*, int) + 50 (juce_VST3_Wrapper.cpp:1326)
1 com.juce.JuceDemoPlugin 0x0000000137da83e3 juce::JuceVST3Component::loadStateData(void const*, int) + 35 (juce_VST3_Wrapper.cpp:1348)
2 com.juce.JuceDemoPlugin 0x0000000137da75c7 juce::JuceVST3Component::readFromMemoryStream(Steinberg::IBStream*) + 583 (juce_VST3_Wrapper.cpp:1369)
3 com.juce.JuceDemoPlugin 0x0000000137d9ff9e juce::JuceVST3Component::setState(Steinberg::IBStream*) + 158 (juce_VST3_Wrapper.cpp:1410)
4 com.steinberg.cubase9 0x0000000110cdf684 0x10f4a8000 + 25392772
5 com.steinberg.cubase9 0x0000000110cdf209 0x10f4a8000 + 25391625
6 com.steinberg.cubase9 0x0000000110820347 0x10f4a8000 + 20415303
7 com.steinberg.cubase9 0x000000011081b712 0x10f4a8000 + 20395794
8 com.steinberg.cubase9 0x000000011081971b 0x10f4a8000 + 20387611
9 com.steinberg.cubase9 0x000000011107bf55 0x10f4a8000 + 29179733
10 com.steinberg.cubase9 0x000000011107d9ba 0x10f4a8000 + 29186490
11 com.steinberg.cubase9 0x00000001110b4994 0x10f4a8000 + 29411732
12 com.steinberg.cubase9 0x00000001110b4994 0x10f4a8000 + 29411732
13 com.steinberg.cubase9 0x00000001110b4994 0x10f4a8000 + 29411732
14 com.steinberg.cubase9 0x0000000110ed9be4 0x10f4a8000 + 27466724
15 com.steinberg.cubase9 0x00000001110b4994 0x10f4a8000 + 29411732
16 com.steinberg.cubase9 0x00000001110b4994 0x10f4a8000 + 29411732
17 com.steinberg.cubase9 0x0000000110ed9be4 0x10f4a8000 + 27466724
18 com.steinberg.cubase9 0x00000001110b4994 0x10f4a8000 + 29411732
19 com.steinberg.cubase9 0x00000001110b4994 0x10f4a8000 + 29411732
20 com.steinberg.cubase9 0x0000000110ed9be4 0x10f4a8000 + 27466724
21 com.steinberg.cubase9 0x00000001110b4994 0x10f4a8000 + 29411732
22 com.steinberg.cubase9 0x00000001110d4733 0x10f4a8000 + 29542195
23 com.steinberg.cubase9 0x00000001110d409a 0x10f4a8000 + 29540506
24 com.steinberg.cubase9 0x0000000111106442 0x10f4a8000 + 29746242
25 com.steinberg.cubase9 0x0000000111106b36 0x10f4a8000 + 29748022
26 com.apple.AppKit 0x00007fff86c0bab7 -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 6341
27 com.apple.AppKit 0x00007fff86c082d4 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 1942
28 com.apple.AppKit 0x00007fff86c07772 -[NSWindow(NSEventRouting) sendEvent:] + 541
29 com.apple.AppKit 0x00007fff86a900a9 -[NSApplication(NSEvent) sendEvent:] + 1145
30 com.steinberg.cubase9 0x0000000110d15b3f 0x10f4a8000 + 25615167
31 com.apple.AppKit 0x00007fff8630c4b1 -[NSApplication run] + 1002
32 com.steinberg.cubase9 0x00000001110f1dfe 0x10f4a8000 + 29662718
33 com.steinberg.cubase9 0x0000000110f1ff4d 0x10f4a8000 + 27754317
34 com.steinberg.cubase9 0x0000000110d0ffba 0x10f4a8000 + 25591738
35 com.steinberg.cubase9 0x0000000110d150eb 0x10f4a8000 + 25612523
36 libdyld.dylib 0x00007fff9dd3e255 start + 1

That line number doesn’t match-up with the code that’s currently in juce - please make sure you’re building with the latest develop-branch juce version, otherwise we can’t help!

Quite right, sorry about that, I opened the project from the wrong repository!

It’s definitely better from the latest commit, however I do still get a crash after I’ve clicked the A/B button a few times:

Exactly the same stack as above, just in loadVST2CompatibleState() on line 1332 of the VST3 Wrapper…

That line still doesn’t make sense, 1332 is the function declaration, not an actual statement.

just in loadVST2CompatibleState() declared on line 1332 of the VST3 Wrapper…

Sorry for the confusion, that’s the method it is crashing in, the actual line is 1337:
if (htonl ((juce::int32) data) == ‘VstW’)

Given that Fabian couldn’t reproduce this, could you give us a bit more help about what’s happening…? Can you catch it in the debugger and see what the state of the data and size values are? It doesn’t look like they can be null or invalid, but perhaps on your machine there’s some weird edge-case where they are…

I’ve just reproduced this exactly as Luke describes. One thing to note is that I initially made the silly error of loading the VST2 not the VST3, and the VST3 SDK is 3.6.6.

So is the host providing a null pointer somehow?

It seems like the data is valid until the cast to (const char*). In the first screen shot (left), the data pointer and size int look valid enough, but once they are passed to loadVST2CompatibleState() (right) the pointer looks like it’s now pointing to nothing.

(Sorry for the dodgy screen shot, the forum wouldn’t let me upload two separate images…).

That’s just the debugger not showing it correctly, the case to const char* doesn’t actually change anything. Really no idea what’s going on there, it really just looks like the host is providing a pointer that’s junk…

Ahh… that’s how I am now able to re-produce this…

1 Like

OK, it turns out the Cubase 9 “lies” about the stream size. It will tell you that the stream has more bytes than it actually has. I’ve just pushed a workaround on develop.


Is it worth letting Steinberg know about this?

1 Like

Excellent! I will pull that and test it on my end and let you know if it fixes the problem for me, too.

And +1 for notifying Steinberg of this if possible.

That has definitely fixed the crash for both A/B switching and copying/pasting settings to another instance.

Thank you, Fabian!

1 Like