Sybiosis 1.3 x32 Crashing, but not x64

[Robert Jonkman]

Hi, I'm trying to figure a nasty bug with my symbiosis wrapped plugin (option 5).  I'm hoping someone may have seen this before.  I'm getting the following error when opening the GUI for the 32bit version of my plugin.

Assertion failed: (vstDispatchReturn != 0), function getEditorDimensions

This only occurs when loading a project that has already has my plugin in it. Inserting a new instance of plugin, the GUI loads just fine.  I'm including the full crash report below.  Thanks in advance for any advice you can offer.

Regards,

Rob 

Process:         REAPER [959]

Path:            /Applications/REAPER.app/Contents/MacOS/REAPER

Identifier:      com.cockos.reaper

Version:         ??? (4.31)

Code Type:       X86 (Native)

Parent Process:  launchd [171]

Date/Time:       2014-04-06 10:45:42.743 +0800

OS Version:      Mac OS X 10.7.4 (11E53)

Report Version:  9

Interval Since Last Report:          591043 sec

Crashes Since Last Report:           153

Per-App Interval Since Last Report:  36348 sec

Per-App Crashes Since Last Report:   54

Anonymous UUID:                      D750204A-F5EE-4C10-BC33-1100683E0B5B

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

Exception Type:  EXC_CRASH (SIGABRT)

Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:

objc[959]: garbage collection is OFF

Assertion failed: (vstDispatchReturn != 0), function getEditorDimensions, file /Volumes/SHARED/ExpressOSX/MIDI Expresion/MIDI Expression AU/Symbiosis.mm, line 1696.

 

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

0   libsystem_kernel.dylib         0x9ceda9c6 __pthread_kill + 10

1   libsystem_c.dylib             0x90b08f78 pthread_kill + 106

2   libsystem_c.dylib             0x90af9bdd abort + 167

3   libsystem_c.dylib             0x90b2e20b __assert_rtn + 351

4   com.audiofront.MIDI-Expression-AU 0x0d6671d8 VSTPlugIn::getEditorDimensions(int&, int&) + 240 (Symbiosis.mm:1696)

5   com.audiofront.MIDI-Expression-AU 0x0d668ce2 SymbiosisComponent::createView(OpaqueControlRef**, Float32Point const&, Float32Point const&, OpaqueControlRef*, OpaqueWindowPtr*, ComponentInstanceRecord*) + 456 (Symbiosis.mm:4943)

6   com.audiofront.MIDI-Expression-AU 0x0d669ad2 SymbiosisViewEntry + 934 (Symbiosis.mm:5253)

[Magnus Lidström]

Strictly speaking that's not actually a crash but an abort due to a failed assert. (It's possible to implement your own assertion handler in Symbiosis. However, Apple's crash reports are so good that it is usually better to just let them abort.) 

The assert says that your VST's getRect() function is not returning true. Can you think of a reason why this would happen?

/ M

--
You received this message because you are subscribed to the Google Groups "Symbiosis AU VST" group.
To unsubscribe from this group and stop receiving emails from it, send an email to symbiosis-au-v...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Admiral Quality]

Try defining the rect dimensions in the editor constructor instead of
in editor::open().

rect.left = 0;
rect.top = 0;
rect.right = iBGWidth;
rect.bottom = iBGHeight;

It's not just Symbiosis that needs this, lots of VST hosts do as well.
But the VSTGUI examples wait until editor::open() to set it. (If I
remember correctly. Let us know if it helps.)

- Mike/AQ

[Robert Jonkman]

I do set the rectangle size in the open method, so it's not that.  I've written a couple extra methods and I suspect one of them called setRect is likely overriding something.  I'll try renaming that and see if it gets me anywhere.

Thanks

[Robert Jonkman]

I wish I knew what happened to resolve the issue, but everything seems to be working fine after a reboot.  I suspect is was some sort of dangling pointer issue.  

Regards,

Rob 

[Robert Jonkman]

Thanks for the help, guys.  Unfortunately the problem has come back.  Magnus, you pointed out that the getRect() function must be returning false, but looking at the function, this seems impossible:

bool AEffGUIEditor::getRect (ERect **ppErect)

{

*ppErect = ▭

return true;

}

The only other place where I could be getting a false value seems to be from the dispatch() method.  Here's the relevant code:

case effEditGetRect: if (editor) v = editor->getRect ((ERect**)ptr) ? 1 : 0; break;

Given that v is initialized as false, am I correct in assuming the only way for this to return false is if the editor pointer is also false?

Regards,

Rob

[Magnus Lidström]

Given that v is initialized as false, am I correct in assuming the only way for this to return false is if the editor pointer is also false?

Sounds like a reasonable assumption. Only one way to find out for sure: debug.

Check that you do create the editor successfully and that you set it with setEditor before VSTPluginMain returns control to Symbiosis.

/ M

[Admiral Quality]

If the editor pointer is false, it'll crash, not return zero. Test for
the validity (!= 0) of the editor pointer before using it. (Though
that's still a somewhat dangerous race condition.)

And yes, debug is our friend. :)

- Mike/AQ

[Magnus Lidström]

The VST SDK code does test for != 0 ("if (editor)" is the same thing).
An assert here would have been a better idea but it's fairly obvious
that Steinberg knew very little of Design By Contract when they designed
VST.

/ M

[Admiral Quality]

Yep.

[Robert Jonkman]

So, I finally figured out how to setup proper debugging on Xcode.  I'm primarily a windows man.

Thankfully, the assert broke reliably during debugging.  Setting up breakpoints in the dispatch and getRect() functions, I managed to get two important bits of information.  Firstly, the editor pointer is not null and secondly, getRect() is never called.

This must mean that the editor pointer is somehow invalid?  Any suggestions as to where I should look next?

[Admiral Quality]

That shouldn't be the case. If new returns anything other than 0 when
you create the editor in the effect constructor, then it didn't fail.

- M

[Magnus Lidström]

This is beginning to sound very strange, but if you step into the getRect function from the dispatcher code you showed us earlier you should be able to see *which* getRect is actually being called and why it is returning 0.

An *invalid* editor pointer would surely make your plug-in crash hard, so that can't be it really.

/ M

[Robert Jonkman]

Very strange indeed.... getRect() is not being called because it's calling this instead:

void AudioEffectX::DECLARE_VST_DEPRECATED (wantAsyncOperation) (bool state)

{

if (state)

cEffect.flags |= DECLARE_VST_DEPRECATED (effFlagsExtIsAsync);

else

cEffect.flags &= ~DECLARE_VST_DEPRECATED (effFlagsExtIsAsync);

[Magnus Lidström]

Wooh. It is getting weirder. How did you wrap your plug-in? With the pre-built wrappers or by including the .mm file? If this happened all the time I would be inclined to believe there is a binary mix-up between VST 2.3 and VST 2.4 (as their virtual tables are probably different), but you started this topic explaining that it doesn't happen for your first plug-in instance?

Could you verify this by stepping into the debugger on your first (successful) instance to see that getRect() is being called there?

/ M

[Robert Jonkman]

I've included the .mm file.  It happens about 50% of the time with the 32bit AU and never with the 64bit.  Upon instantiation, there are no issues.  It only ever happens on loading a previously saved project.

[Admiral Quality]

Did the plugin state saved in the old project have the same number of
controls as the latest version of the plugin? That's always a good one
for causing problems, if you don't check your control indexes
carefully.

- M

[Robert Jonkman]

I think I've managed to sort it out.  Here's the fix, I incremented the amount of memory I use for programs (presets) from 1 to 2, even though I my effect constructor only specifies 1.

Regards,
Rob

[Admiral Quality]

Sounds like you're stomping on something.

What do you declare right after your program data array? And what's
the last item in your program data array? They might be things you
want to watch in the debugger.

I'm also faintly remembering something about Symbiosis and
single-program effects, like you say yours is. Offhand I can't
remember exactly what the issue was or if it's fixed now. Is
setProgram() etc, being called with a valid index? (In your case, only
zero is valid.)

- AQ

[Robert Jonkman]

After the program data, I instantiate my editor, so they are definitely adjacent.  the last bit in the program data is the name of the preset which is char[24].  

I put a breakpoint in the setProgamName() method and everything checks out. 1 program and curProgram is 0.  I'm at a loss, but at least it's working. 

It might be worth mentioning that I was debugging with Malloc Guard when I figured out there was something up with the programs.  It was complaining about a BAD_ACCESS in the vst_strncpy method when trying to zero the dst pointer.  Does that mean anything?

Anyways, I'll have to do so more testing, but for I'm just happy that I'm making progress.

Rob