Might as well join in on the Apple bug reporting Friday fun. Since Tiger's release on April 29th, 2005, we've been receiving quite a few emails about an iSync crash. All of them blaming the crash on APE for some reason or another. This crash is not caused by APE or any APE Module. We've just received so many reports of the crash that, much like the previous Bluetooth Menu Extra bugfix (which was done on a Saturday, not a Friday), I just decided to spend some time and "fix" the darn bug. I mean, we're getting blamed for it anyways. And with that, birth was given to iSyncWorkaroundDealie (iSWAD). I use "fix" in quotes because this workaround is not ideal in any way. Apple should definitely not do anything like this to address the issue. This just prevents the crash from happening so you can use iSync without it crashing.

My first action was, of course, to reduce the bug and report it to Apple. And yes, I did make sure that APE wasn't even installed in the very first crash log I sent. However, the message returned was "remove all haxies and try again". ARG! I had already removed all haxies. I can't remove what's already been removed. So let's just say that I got a little hostile in the bug report. Then RadarWeb did it's lame thing it always does and started being weird. First it'd pretend as if the new crash log I uploaded was successfully uploaded, but it wasn't. Then when I tried to paste it inline, it failed.. but it really didn't fail. All was not lost. The comments on this bug shed light on the real problem, however.

It's actually caused because iSync uses a GCC supported feature called nested functions. When nested functions are used and a CFM library/PEF Binary (the native executable format for the PowerPC) is loaded, all hell breaks loose... basically. Something about loading the CFM runtime causes the stack to just get hosed and it seems iSync crashes the next time CFArrayApplyFunction is called. This usually happens inside of -[ISyncMainWindowController enableDevices:], although in rare circumstances it may happen inside any method call. So this is technically a bug somewhere in Mac OS X, but iSync seems to be the only one that suffers from the problem.

PEF Binaries aren't that unique on OS X. There are quite a few PEF Contextual Menu Modules, QuickTime Plugins, and Scripting Additions being used on OS X as the amount of emails we've received on the problem clearly demonstrates (to us at least). For instance, Adobe Photoshop CS and later requires a scripting addition called "Adobe Unit Types" to function. So if you have Adobe Photoshop CS or later and iSync 2.0 or later the following script will crash (even if you never use iSync):

tell application "iSync"

	set blah to current date

	synchronize

end tell

Alternatively, iSync will also crash if you have any PEF CMM modules. To test this, open the about box of iSync and right click some text. This loads all the Contextual Menu Modules. If one of the loaded CMMs is a PEF Binary, clicking the Sync button in iSync will cause a crash. Again, you don't have to actually have ever synced any devices to get this crash.

If you want to "prevent" the crash without actually installing APE, you can as long as you don't require the use of Adobe Photoshop CS. Just open the ~/Library/Logs/CrashReporter/iSync.crash.log and search the log for "PEF Binary". Ignore all the lines that start with CFMPriv_ as these are PEF Binaries included with OS X and are loaded to handle the CFM calls. Once you find the name of a PEF Binary, look in Library/Contextual Menu Items/, Library/QuickTime/, and Library/ScriptingAdditions/. The missing slash (/) at the beginning denotes it can be in any Library folder (excluding the /Sytem/Library/ folder, do not touch that one) such as the one at the root of the hard drive, or the one in your user folder. After you remove a specific PEF Binary from the hierarchy, rerun the iSync test and see if it continues to crash, if it does, start from the beginning of this paragraph again.

My first attempt (the source code to it) involved trying to re-implement CFArrayApplyFunction by copying and pasting a lot of the CFArray source code and then trying to find out where it crashed. Luckily, it did not work. It'd stop crashing inside enableDevices: and would then crash in some other random place. So that 8+ hours of trying that approach was a dead end. I wouldn't say it was a waste of time as it taught me to hate the CF code a lot more. Not that I didn't loathe it already.

Then I decided on trying to prevent any CFM Libraries from loading. And that's what actually worked. You can download the "fix" here. It will only load into iSync and won't touch any other processes. The linked disk image contains the source code and the compiled APE module. You'll need to download Application Enhancer to use the APE module (install it in ~/Library/Application Enhancers/) and if you want to compile the project you'll need Xcode 2.1 or later and the APE SDK.

Download iSyncWorkaroundDealie.dmg (72k)