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.
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.
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?
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.
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.
Thank you Arne. It only requires a call to MIDIGetNumberOfDestinations in Apple’s CoreMIDI during plugin construction to make vst2xscanner crash.
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.