Interpreting Crash Logs With otx
So now we have the disassembly of the plugin, but the offsets of the crashlog cannot be found. The offsets produced by otx start at 0×00000f54 and go to 0×000024f3. That’s not nearly close to 0×179d383c. The reason behind that is simple: the plugin’s code is mapped into the memory where the linker things it got some space left. So we need to find out where the plugin was mapped in order to find the right spot in the disassembly.
The stack trace ended up looking funny in the crash log because of double method swizzling. I’ve run into the same issue with SpamSieve’s Apple Mail plug-in. SpamSieve always installs it in ~/Library/Mail/Bundles, but on some Macs another copy is installed in /Library/Mail/Bundles. (No user has admitted to putting it there, and it’s happened enough times that I think there must be some other software moving/copying it there. A mystery.) The plug-in now disables itself if another copy has already been loaded. For this crash, it was evident from the Binary Images section of the crash report what had happened, but it’s good to have otx in your toolbox.
