Crash crash

Software developers have an awesome power, even greater than that ascribed to the late Timothy Leary by the Moody Blues. A developer’s software can take you up and bring you down – to your knees, if they wish. The right bug in the right place can have devastating effects.

If you ever suffered from Microsoft Word’s ‘too many files open’ bug in Mac OS 8 or 9, you will recall just what I mean. Sometimes when file sharing was turned on, Word seemed to leave too many files open, so that when you tried to save your active document, it refused with said complaint. Then you were truly stuck: you could not save the changed document, so you had to accept that all changes since the last successful save were blown away. I have known robust adults become tearful wrecks as a result.

I once perpetrated an even ‘better’ bug, capable of making the user feel quite nauseated. My defective code inadvertently accessed the wrong area of memory that was (unknown to me, and wholly unintentionally) part of the control set for the graphics card. Whenever the bug occurred, it upset the monitor hold, setting the screen into a steady roll. The only way out of this was to pull down a menu command, no mean feat when mouse pointer, menu bar and the whole caboodle are rolling steadily past your eyes, and highly nauseogenic. Who needs a costly VR headset to make a user throw up?

Although Apple (and I) keep telling you how robust Mac OS X is, that does not mean that there will ever be an end to all bugs, as I am sure that you will have experienced. Applications can still crash, but in the main they do not take the operating system with them, simply signing off with a farewell alert.

Caring developers can link such events to a bug reporting system, such as Crash Reporter, which should automatically send full details of the machine state, etc., when the crash occurred. At least they can provided that Crash Reporter doesn’t cause problems of its own.

Writing debugging and similar tools is an art in itself, as the great Steve Jasik, author of the former 68K Mac tools MacNosy and The Debugger, knew so well. Your debugging tool only ever gets called when something has fallen over, and everything is in a degree of disarray. So all debugging tools must be extremely clean and robust.

For a while, quite a few users and OS X Server system administrators came to associate Crash Reporter with further crashes, sometimes even a kernel panic, the ultimate achievement of any ambitious bug. Turning Crash Reporter off seemed to cure some Macs that had frequent or repeated problems.

In old versions of OS X, this could be achieved by first checking whether it was turned on, typing
more /etc/hostconfig
at Terminal’s command line. If the line CRASHREPORTER=-YES- appeared in the file, then Crash Reporter was turned on. You could then it off by changing the YES to NO, and you might have found that OS X crashes were handled more gracefully. Since then, the hostconfig file has gone west, so this technique is now broken.

This also became more complicated in more recent releases of OS X. A useful but now old developer Tech Note, which also explains how to try to interpret crash logs detailed much about those newer controls.

More recent still, Crash Reporter became controlled by yet another XML Property List (.plist) file, so the Terminal command to disable it became
defaults write com.apple.CrashReporter DialogType none
and
defaults write com.apple.CrashReporter DialogType crashreport
turned it back on again.

Now the generation of crash reports is the task of ReportCrash, which is automatically invoked by the OS X launch service launchd when a crash is detected. You are therefore recommended to use the command line utility launchctl to control crash reporting, according to ReportCrash‘s man page. So to disable crash reporting, you should type the following two lines in Terminal:
launchctl unload -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist

You can then restore crash reporting with the following two lines:
launchctl load -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist

If you don’t fancy those, this is not an easy task for third-party utilities which can normally only change the type of dialog presented after a crash, but Lingon X (the $10 shareware version, not the App Store one) can save you having to tackle it in Terminal.

lingonxIf that sounds too techie to be useful, consider this possibility. Let’s say that the crash that occurred hit a service, lookupd which performs name server lookups, not an application. If Crash Reporter or ReportCrash is turned on, once lookupd crashes, a crash log will be generated and sent to Apple. Only now crashreporterd or ReportCrash, the service that sends the report, needs to use lookupd to do its job. This is too much, and the whole Mac can lock up. You can still send bug and crash reports to Apple and other vendors manually, and you should always do so if you come across a significant bug, lest the developer continues to think that there is no problem.

At least you shouldn’t need to dip into your collection of airline puke bags, as my users once came close to doing.

Updated from the original, which was first published in MacUser volume 20 issue 10, 2004.