With the release of the latest R13 service update, some plugins started crashing on OS X. When R14 was released, the problem got worse. A lot of plugins crashed on OS X, either immediately when CINEMA 4D was started, or when a window or dialog was closed.
What made this error so hard to find was the fact, that it did not occur on every machine. And even if the crash was reproducable, the debugger always ended up in a different location of the code (but it was always in CINEMA 4D, and not in the plugin that caused the crash).
Why did it happen?
When creating the project file for a CINEMA 4D plugin, most people usually copy the cinema4dsdk.xcodeproj, rename it, throw in their own sources, and change the product name. That is a legitimate way to create the project file for a CINEMA 4D plugin. However, if the cinema4dsdk.xcodeproj of the R12 SDK was used, a setting in the release build settings was wrong.
When creating release build, usually all non-global symbols have to be stripped from the plugin binary. In the R12 SDK project, the Stip Style was set wrong: It would only strip out the debug symbols. As a result, even critical symbols like new and delete have been exported and then used by the operating system. Hence, when closing a dialog or allocating or freeing any resources, the new and delete from the plugin binary would be used instead of the appropriate functions from the CINEMA 4D SDK that would use CINEMA 4D’s own memory management. That is what caused the crash. But after all, it depended on timing and contents of the memory if a crash would actually occur.
The weird thing is, even when the Strip Style was correctly set to Non-Global Symbols, the stripper would always throw an error and now perform any stripping at all. It might be an unfortunate combination of project settings or a bug in the Xcode 3.2.6 stripper, which is also not totally unlikely. Probably both of them.
Anyway, in R12 plugins would not crash, but that seems to be pure coincidence. In R13 and R14, different parts of the CINEMA 4D core have been changed, and while none of those changes concerned the handling of plugins, it was enough change to make the problem of exported symbols apparent.
The faulty setting
Two screenshots of Xcode 3.2.6, showing the critical setting.
Why doesn’t MAXON fix it?
There is nothing MAXON could do about it. The problem has been identified, and information has been posted on PluginCafé. But as the problem is in the plugin developers’ binaries, it is the plugin developers who have to fix it. As long as those symbols are exported in the plugin binaries, the operating system will attempt to use them. The R13 and R14 SKD project files are totally fine, so the problem will not occur in plugins compiled in those releases, anyway.
How to fix it
Since a plugin build with a project file that was derived from the R12 SDK project does not crash in R12, plugin developers only have to care about their builds for R13 and R14. Even though the CINEMA 4D API allows using R12-compiled plugins in R13 and R14, it is strongly recommended to build a separate version for R13 (will also run in R14). Remember: All this only concerns OS X. Windows builds of any plugins have no problem.
Plugin developers just have to rebuild their plugins in R13, using a project file derived from the R13 SDK project. This will immediately fix all problems. However, some minor changes in the code may be needed to successfully compile it, since some parts in the API have changed, e.g. the SplineCustomGui and SplineData member functions, or all functions like HPBToMatrix(). See the changelist in the SDK documentation.
In a nutshell: If you compiled your plugin in R12, you will have to make a rebuild in R13 to make it usable in R13 and R14 on Mac. For R13, Xcode 3.2.6 is still used (plugin will run in R14, too). If you compile specifically for R14, Xcode 4.5 has to be used. The only important thing is that R12 builds of plugins should not be used in R13 or R14.
