Os x plugin problems

It seems like the tip’s PluginHosts’s OS X plugin scan code does not do its job well. It often crashes or hangs, it doesn’t matter if VST or AU.

With D16 Drumazon (seems to be a JUCE plugin itself) I get: (The plugin does work in Logic)

#0 0x90c756e4 in objc_msgSend #1 0x002b6b38 in juce::NSViewComponentPeer::NSViewComponentPeer at juce_mac_NSViewComponentPeer.mm:883 #2 0x002b6ffa in juce::Component::createNewPeer at juce_mac_NSViewComponentPeer.mm:1715 #3 0x1734815f in juce::Component::setColour #4 0x17379a03 in juce::LookAndFeel::createSliderTextBox #5 0x17388993 in juce::Slider::lookAndFeelChanged #6 0x173893f1 in juce::Slider::Slider #7 0x171a4cff in GFXKnob::GFXKnob #8 0x171c4a61 in BasePluginEditor::importPluginEditorFromXml #9 0x171c4f9d in BasePluginEditor::importPluginEditorFromResource #10 0x171c5a5b in BasePluginEditor::BasePluginEditor #11 0x17424680 in InstrumentEditor::InstrumentEditor #12 0x1741b227 in DrumMachineEditor::DrumMachineEditor #13 0x174276f0 in DrumazonEditor::DrumazonEditor #14 0x17424899 in Drumazon::createBasePluginEditor #15 0x171c090d in BasePlugin::initialize #16 0x17416155 in DrumMachine::initialize #17 0x171bae57 in createPluginFilter

Another candidate, Sony Oxford EQ+Filters, as reported by a friend of mine:

[code]
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000dededeff
Crashed Thread: 0

Thread 0 Crashed:
0 …sony.audiounit.SonyOxfordEQ 0x19d885d1 SonyOxfordEQViewEntry + 82825
1 …sony.audiounit.SonyOxfordEQ 0x19d86b66 SonyOxfordEQViewEntry + 76062
2 …sony.audiounit.SonyOxfordEQ 0x19d86fae SonyOxfordEQViewEntry + 77158
3 …sony.audiounit.SonyOxfordEQ 0x19dd741a 0x19d58000 + 521242
4 …sony.audiounit.SonyOxfordEQ 0x19d5fc68 0x19d58000 + 31848
5 …sony.audiounit.SonyOxfordEQ 0x19d5e31a 0x19d58000 + 25370
6 …sony.audiounit.SonyOxfordEQ 0x19d732a5 SonyOxfordEQEntry + 33
7 …ple.CoreServices.CarbonCore 0x9636e5cd CallComponentDispatch + 29
8 …ple.CoreServices.CarbonCore 0x9636f30d CallComponentClose + 43
9 …ple.CoreServices.CarbonCore 0x9636f231 CloseComponentInternal(ComponentInstanceRecord*) + 101
10 …ple.CoreServices.CarbonCore 0x9636f1b2 CloseComponent + 46
11 com.schaack.sequencer 0x000d390e juce::AudioUnitPluginInstance::~AudioUnitPluginInstance() + 98
12 com.schaack.sequencer 0x000d5d79 juce::ScopedPointerjuce::AudioPluginInstance::~ScopedPointer() + 37
13 com.schaack.sequencer 0x000d48a9 juce::AudioUnitPluginFormat::findAllTypesForFile(juce::OwnedArray<juce::PluginDescription, juce::DummyCriticalSection>&, juce::String const&) + 301[/code]

The scenario is pretty much always the same: Takes ages, spinning wheel shows up and a few minutes later crash.

Whenever I see a crash in an obj-c dispatcher, the main suspect must be an objective-c class name clash - did you make sure your host has the JUCE_ObjCExtraSuffix value set?

Is the sony oxford also a juce plugin? The entry point names look like the old juce-style carbon naming convention. Maybe a quick ‘strings’ on the binary might reveal some clues about that.

I tried with your plugin host and it’s the same. I just compiled the plugin host XCode project as is without any modification, same result. Funny thing is it doesn’t always happen, just sometimes. Don’t think the Sonnox stuff is JUCE-based, up to you to judge that.

I’m 100% sure the sonnox eq is not a JUCE plugin, I’ve checked using strings. Do you have any idea? I’m stuck when it comes to analyzing Obj-C code.

Can’t think of any other clues, I’m afraid… Plugins can be frustrating to debug from the outside - it might actually be worth pinging the makers and asking if they’ve tried it themselves.

Have you at least tried the aforementioned plugins yourself? No need pinging the makers when in every host other than JUCE these plugins do work!

No, I’ve not tried them. The main reason I suggested pinging them is that you can sit for days trying to figure out why a plugin is crashing, and get nowhere… (I’ve wasted far too much of my life doing exactly that, which is why I’m reluctant to offer to help with this).

And just because a plugin works in every other host doesn’t mean that it’s the host’s fault that it’s crashing! I’ve often seen hosts do perfectly sensible things that cause plugins to crash for mysterious internal reasons that you’d be powerless to figure out from the outside.

C’mon, at least please try the Sonnox one. It crashes EVERY time. If this was just some stupid amateur-freeware-plugin crashing, I’d say “ok, I understand your point” - but this is a kind of ‘reference’ plugin that’s crashing. I’m sure everybody in this forum will appreciate your time well spent.

.apart from the client who’s paying me to do some other work this week! If I was sure it’d only take 10 mins then I’d take a look, but investigating plugins always ends up dragging on for hours/days, which I can’t spare right now! I’ll have a look as soon as I can!

Any news? It’s been a while. …

Sorry, but trying to track down bugs in other people’s plugins, without the source code, is a low priority for me! Contact the makers and tell them - they should be able to simply catch it in the debugger and see what’s happening. If I investigate, I could waste days and may discover nothing at all.

[quote=“zamrate”]It seems like the tip’s PluginHosts’s OS X plugin scan code does not do its job well. It often crashes or hangs, it doesn’t matter if VST or AU.

With D16 Drumazon (seems to be a JUCE plugin itself) I get: (The plugin does work in Logic)

#0 0x90c756e4 in objc_msgSend #1 0x002b6b38 in juce::NSViewComponentPeer::NSViewComponentPeer at juce_mac_NSViewComponentPeer.mm:883 #2 0x002b6ffa in juce::Component::createNewPeer at juce_mac_NSViewComponentPeer.mm:1715 #3 0x1734815f in juce::Component::setColour #4 0x17379a03 in juce::LookAndFeel::createSliderTextBox #5 0x17388993 in juce::Slider::lookAndFeelChanged #6 0x173893f1 in juce::Slider::Slider #7 0x171a4cff in GFXKnob::GFXKnob #8 0x171c4a61 in BasePluginEditor::importPluginEditorFromXml #9 0x171c4f9d in BasePluginEditor::importPluginEditorFromResource #10 0x171c5a5b in BasePluginEditor::BasePluginEditor #11 0x17424680 in InstrumentEditor::InstrumentEditor #12 0x1741b227 in DrumMachineEditor::DrumMachineEditor #13 0x174276f0 in DrumazonEditor::DrumazonEditor #14 0x17424899 in Drumazon::createBasePluginEditor #15 0x171c090d in BasePlugin::initialize #16 0x17416155 in DrumMachine::initialize #17 0x171bae57 in createPluginFilter[/quote]

I got exactly the same kind of stack and problem with another D16 plugin, Nepheton.
The weird thing was that the plugin was working in juce plugin host application, but crashing in my host app.

I tried to recompile everything with a custom JUCE_ObjCExtraSuffix, but it did nothing. Which I expected because the suffix was already set on some kind of hexa string (I suppose it is generated by Jules at some point in the release), and I doubt the D16 plugin uses exactly the same string. Besides, if it was working with the plugin host application, why wouldn’t it work in my app with the same underlying juce library? The only difference is that my app links statically and the host app uses juce amalgamated…
Then I saw that the plugin host application project had the option to hide the symbols by default. I tried to recompile my project and all its dependencies with this option and now it seems to work.

I’m not a linker guru, so I don’t really understand why it would change anything. I thought symbol visibility was only for dynamic libraries? Does anyone have the Knowledge about that?
I’m still not sure it was this change that did the trick but I don’t see what else I did that could have make it work…