On Aug 26, 2012, at 7:14 AM, Paul Miller <paul@fxtech.com> wrote:
I have a plugin that links statically with a third party library. When it is used while another third-party (hi Jim!) plugin (that happens to link DYNAMICALLY with a different version of the *same* library) is present in the Plugins folder, FCPX crashes.
The crash stack trace follows my code down into my static copy of the third-party library, then it jumps into the dynamic version of the library that is present in the other plugin (which is not applied to the clip, it's just present in the plugin folder).
This all happens because of the extremely lazy binding going on by default in Objective C programs. I would expect it to call into my *statically linked* version of the code, but it ends up in what I suspect is the first code it encounters with the same function signature, which in this case is in someone else' (incompatible) library.
I've got a question into the linking people to see if they have any suggestions. I'll let you know what I find.
Is there any way to work around with XCode linker options to more permanently bind the function addresses of my code? And although I like having verbose stack traces, I wouldn't mind turning off the option that exposes all of my function names. I'm sure users do not want to see functions such as "WellBleepMeWithaBagOfDildos()" in their crash reports.
For this, you could probably strip symbols from your plug-in, couldn't you? I'm pretty sure I've seen stack traces where 3rd party plug-ins show up as just addresses with no names in them, so I think some people are doing this already. Note however that it can be helpful to us at Apple to know that a particular plug-in was involved in a crash. If it's one we have on hand, we can just drop it in and see if we can reproduce the problem, and if it's on our end get to fixing it, or notify you if we think it's on your end. If there's no indication of what plug-in it was, we have to try to contact the customer, and if we're lucky they'll be able to tell us which one it was, and then we can finally get to work on it. Darrin _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com