New vstscanner versions

SDK for VST 3 audio plug-in and host development.
Arne Scheffler
Posts: 383
Joined: Mon Jun 20, 2016 7:53 am

Re: New vstscanner versions

Post by Arne Scheffler »

markovic wrote: Yes, the plug-in GUI and linked GUI framework use several Objective-C classes and at least one category method.
But you don't add functionality to classes from Apple's frameworks ? If you do you need to put this into a separate framework or dylib so that this one is not unloaded when your plug-in is unloaded.

markovic
Posts: 7
Joined: Mon Jun 27, 2016 11:52 am

Re: New vstscanner versions

Post by markovic »

Thanks Arne,

I understand that the crash happens when/after unloading a plugin, is that so?
Some Apple documentation still says that unloading Objective-C is not possible, could be that it was not updated:
Because of a limitation in the Objective-C runtime system, NSBundle cannot unload executable code.

Arne Scheffler
Posts: 383
Joined: Mon Jun 20, 2016 7:53 am

Re: New vstscanner versions

Post by Arne Scheffler »

markovic wrote:Thanks Arne,

I understand that the crash happens when/after unloading a plugin, is that so?
Some Apple documentation still says that unloading Objective-C is not possible, could be that it was not updated:
Because of a limitation in the Objective-C runtime system, NSBundle cannot unload executable code.
Please see : https://opensource.apple.com/source/obj ... .auto.html

This tests the unload ability of bundles.

markovic
Posts: 7
Joined: Mon Jun 27, 2016 11:52 am

Re: New vstscanner versions

Post by markovic »

Arne Scheffler wrote:
markovic wrote:Thanks Arne,

I understand that the crash happens when/after unloading a plugin, is that so?
Some Apple documentation still says that unloading Objective-C is not possible, could be that it was not updated:
Because of a limitation in the Objective-C runtime system, NSBundle cannot unload executable code.
Please see : https://opensource.apple.com/source/obj ... .auto.html

This tests the unload ability of bundles.
I see... that the objc runtime internally increases open count on dylibs containing Objective-C to prevent them from unloading.
But I cannot find that behavior in latest objc4-706.
Is it possible that that suggested approach with separate dylib might not work since macOS 10.12?

Arne Scheffler
Posts: 383
Joined: Mon Jun 20, 2016 7:53 am

Re: New vstscanner versions

Post by Arne Scheffler »

markovic wrote: I see... that the objc runtime internally increases open count on dylibs containing Objective-C to prevent them from unloading.
Ehm, no, only if it has objective-c meta data other than image info. Otherwise as the cycle() function shows if a plug-in registers classes or protocols they should be able to unload. Why the whole test folder is missing from the open source distribution since 10.12 is out of my knowledge. But I doubt that they changed the unload behaviour.

markovic
Posts: 7
Joined: Mon Jun 27, 2016 11:52 am

Re: New vstscanner versions

Post by markovic »

Arne Scheffler wrote:But I doubt that they changed the unload behaviour.
Because the test folder was missing I compared parts of code which I considered having effect on unloading decisions in objc4-680 and objc4-706.
I see that the extra dlopen() call is now gone from objc-os.mm and is nowhere to be found in the source.
Also _hasObjcContents private function while still defined is not used within the module anymore.
It’s still possible that the unloading logic has been moved outside objc4 but I didn’t go that far to investigate more.

Thanks to your pointers to objc runtime source I found I might use some environmental variables to get better idea what exactly is causing the problem.

Jakob
Posts: 10
Joined: Thu Feb 16, 2017 11:26 am

Re: New vstscanner versions

Post by Jakob »

Arne Scheffler wrote:
Jakob wrote: Hi Arne, thanks a lot for your reply. I just did another test - built with XCode on OS X 10.11, deployment target set to 10.11, "Implicitly Link Objective-C runtime Library" set to off, and calling "juce::MidiOuput::getChannels()" during construction. Still, this makes vst2xscanner crash, printing "Segmentation fault: 11".
Sorry, no idea. If you can strip down the code so that only a few lines will cause this crash I'm happy to look at it.
Thank you Arne. It only requires a call to MIDIGet​Number​Of​Destinations in Apple's CoreMIDI during plugin construction to make vst2xscanner crash.

Jakob
Posts: 10
Joined: Thu Feb 16, 2017 11:26 am

Re: New vstscanner versions

Post by Jakob »

Jakob wrote:
Arne Scheffler wrote:
Jakob wrote: Hi Arne, thanks a lot for your reply. I just did another test - built with XCode on OS X 10.11, deployment target set to 10.11, "Implicitly Link Objective-C runtime Library" set to off, and calling "juce::MidiOuput::getChannels()" during construction. Still, this makes vst2xscanner crash, printing "Segmentation fault: 11".
Sorry, no idea. If you can strip down the code so that only a few lines will cause this crash I'm happy to look at it.
Thank you Arne. It only requires a call to MIDIGet​Number​Of​Destinations in Apple's CoreMIDI during plugin construction to make vst2xscanner crash.
Hi Arne, I am just checking, are you planning to look into this?

Arne Scheffler
Posts: 383
Joined: Mon Jun 20, 2016 7:53 am

Re: New vstscanner versions

Post by Arne Scheffler »

Jakob wrote: Hi Arne, I am just checking, are you planning to look into this?
I'm currently short in time, if you can provide me with a sample project with source where I can check this, would speed this up.

Cheers
Arne

Jakob
Posts: 10
Joined: Thu Feb 16, 2017 11:26 am

Re: New vstscanner versions

Post by Jakob »

Arne Scheffler wrote:
Jakob wrote: Hi Arne, I am just checking, are you planning to look into this?
I'm currently short in time, if you can provide me with a sample project with source where I can check this, would speed this up.

Cheers
Arne
It seems I uncovered the issue. So our plugins are calling "juce::MidiOutput::getDevices()" on construction. This then calls "MIDIGetNumberOfDestinations" from Apple's Core MIDI API.

It's only now that I realized that "MIDIGetNumberOfDestinations" is written in Objective-C. Is there any way to make it pass the scan on old versions of OS X without getting problems from your vst2xscanner?

Note: I am using XCode 8.2.1, Deployment Target set to 10.11, and "Implicitly Link Objective-C Runtime Support" is set to Off.

Post Reply