HELP vst mac cubase - juce plugins kill each other

Audio Plugins
1

A user reported me this issue!

If you use two different newer juce-based-plugins (from different authors) in Cubase and the GUI of the plugins is open

  1. insert plugin a

  2. insert plugin b

  3. remove plugin b

  4. plugin a will crash

  5. insert plugin b

  6. insert plugin a

  7. remove plugin a

  8. plugin b will crash

Can it be that something in the Destructor of the VSTWrapper like deleting outgoing events, or shutdown the juce gui causes this crash?

Also its unclear how this can happen, why both plugins using the same handles/binaryscodebase/etc…
Aofter compiling i remove all symbols (with strip) of my plugin, how can there be a connection between this two plugins?

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS

Call Stack:
juce::MessageManager::deliverMessage(void*)
juce::EventHandlerProc(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*)
SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*)
SendEventToEventTargetWithOptions
ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*)
SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*)
SendEventToEventTarge
CPSOLAAnalysisEnhIf::DestroyInstance(CPSOLAAnalysisEnhIf*)
MpexSetProperty(long, long double, unsigned long, void*)

2

[code]void MessageManager::deliverMessage (void* message)
{
const MessageManagerLock lock;

Message* const m = (Message*) message;
MessageListener* const recipient = m->messageRecipient;

if (messageListeners.contains (recipient))
{
    JUCE_TRY
    {
        recipient->handleMessage (*m);
    }
    JUCE_CATCH_EXCEPTION

    if (needToGetRidOfWaitCursor)
    {
        needToGetRidOfWaitCursor = false;
        MouseCursor::hideWaitCursor();
    }

    ++messageCounter;
}
else if (recipient == 0 && m->intParameter1 == quitMessageId)
{
    quitMessageReceived = true;
    useMaximumForceWhenQuitting = (m->intParameter2 != 0);
}

delete m;   !!!!!!!!!!!!!!!!! Crash happens here  !!!!!!!!!!!!!!!

[/code]

The Crash happens when the plugin tries to delete this message, maybe because its deleted by the other plugin? Any ideas?

3

Have you tried to change the kJUCEClass constant for one of the plugs ? (in juce_Mac_Messaging) . I’m wondering if each (carbon-based) juce plugin should not customize this one ?

4

THANKS!!! Thats it.

5

I have also found this problem, with the crash on delete. It occurs when I do the following:

  • Boot my OS 10.5.6 Mac mini
  • Load Logic 8.0.2 (Mac)
  • Add an instrument channel and insert ultra beat on it
  • Add a tape delay insert on this channel
  • Add my plugin - The Glue
  • Swap The Glue with the tape delay plugin so my plugin is first

Bang, it crashes when trying to delete the message as indicated above.

Any ideas?

Andrew Simper

6

is there another juce-based plugin involved?
Did you change the kJUCEClass constant, it should be individual for every juce-plugin, like the vst-plugin id
This thread should be a sticky, because i think there are much carbon-based plugins out there.

7

There are no other juce plugins I can think of involved, well at leas none are instantiated. I made sure to test only with logics built in plugins to replicate this issue.

8

I will try changing the constant anyway to see if this helps even with logic only plugins.

9

What is the official verdict on this? Do I have to change this for every plugin I write? What about clashes with anyone else using the Juce framework? I have confirmed issues with d16 plugins, but only their plugins that use the Juce framwork.

Andrew Simper

10

I wouldn’t have thought that it made any difference for the old carbon-based stuff, because that uses a random number as conjunction with the kJUCEClass constant.

In the newer obj-c code though, I do very much recommend using a unique JUCE_ObjCExtraSuffix value, due to the way obj-c compulsively tries to dynamically link to anything in its vicinity…

11

I already posted that, but those you might be interested the reason behind this

http://www.cocoabuilder.com/archive/message/cocoa/2008/2/15/198978

12

[quote=“jules”]I wouldn’t have thought that it made any difference for the old carbon-based stuff, because that uses a random number as conjunction with the kJUCEClass constant.

In the newer obj-c code though, I do very much recommend using a unique JUCE_ObjCExtraSuffix value, due to the way obj-c compulsively tries to dynamically link to anything in its vicinity…[/quote]

Do I need to define this for every plugin I write? Perhaps I should have this included in from the JucePluginCharacteristics.h ?

Andrew Simper

13

[quote=“otristan”]I already posted that, but those you might be interested the reason behind this

http://www.cocoabuilder.com/archive/message/cocoa/2008/2/15/198978[/quote]
You already posted what? And where? I just read the thread and didnt’ turn up the JUCE_ObjCExtraSuffix that Jules is talking about, am I missing something?

Andrew Simper

14

I just searched the entire 1.46 code base and could not find the text JUCE_ObjCExtraSuffix anywhere, is this something new?

Andrew Simper

15

[quote=“andrewsimper”][quote=“otristan”]I already posted that, but those you might be interested the reason behind this

http://www.cocoabuilder.com/archive/message/cocoa/2008/2/15/198978[/quote]
You already posted what? And where? I just read the thread and didnt’ turn up the JUCE_ObjCExtraSuffix that Jules is talking about, am I missing something?

Andrew Simper[/quote]

In another thread.
I suppose you’re not using the lastest juce trunk, not sure that the JUCE_ObjCExtraSuffix was in the 1.46 release

16

So is updating to the tip stable for production code? I thought there were issues with it at the moment that need fixing before it is released as 1.47.

Andrew Simper

17 

To be honest I did not manage to reproduce the problem myself, but I don't do not see the random constant that Jules is telling about in my local juce copy (juce svn r595). I see an "UnsignedWide t;Microseconds (&t); kJUCEClass ^= t.lo;" but it is executed only when JUCE_COCOA is defined. 

.. Ok I just looked to juce 1.46, and the kJUCEClass ^= t.lo is not inside a #if JUCE_COCOA .. So I guess plugins that are affected by the problem are those based on the latest SVN revisions just before the cocoa transition, and the fix is obvious, just move the #if JUCE_COCOA three lines below. 

I should have noticed that before.

To be honest I did not manage to reproduce the problem myself, but I don’t do not see the random constant that Jules is telling about in my local juce copy (juce svn r595). I see an “UnsignedWide t;Microseconds (&t); kJUCEClass ^= t.lo;” but it is executed only when JUCE_COCOA is defined.

… Ok I just looked to juce 1.46, and the kJUCEClass ^= t.lo is not inside a #if JUCE_COCOA … So I guess plugins that are affected by the problem are those based on the latest SVN revisions just before the cocoa transition, and the fix is obvious, just move the #if JUCE_COCOA three lines below.

I should have noticed that before.

18

Ahh, yes that looks a bit more reasonable, thanks for your post. I did in fact grab the tip post 1.46 since I was advised to, so I have the code you are talking about which has the #if in the wrong place. Switching to the latest tip is really not an option for me since I have many customers using my plugins in production, and switching hundreds of lines of code would require lots of testing which I don’t have time for right now.

Andrew Simper

19

Is there a list of bug fixes like this somewhere so I can check which of the issues I am having is fixed by which change in the code? Do changes to code get logged against a bug tracking number so I can match the commits to each bug fix?

Andrew Simper

20

[quote=“andrewsimper”]Do changes to code get logged against a bug tracking number so I can match the commits to each bug fix?
[/quote]

LOL! No, there’s no bug-tracking database. I explain what I’ve fixed in the SVN commit messages, but that’s all you get. If I had to mess about with bug-trackers every time I changed anything, nothing would ever get done!