[Note: This is the first of a few columns where I explore the "smaller" changes in Mac OS X 10.4. These are changes that, while they may not get much publicity, are quite relevant for troubleshooting.]
Among the many new features in Mac OS X 10.4 (Tiger), there is one that Apple has never mentioned its marketing material. Probably, this is because it has to do with a topic that Apple rarely talks about anyway: application crashes. I'm talking about those times when the "unexpectedly quit" dialog appears on your screen.
If, as a result of Apple?s reticence (okay; Apple did give this some coverage in one of its Knowledge Base documents), you haven?t yet seen what?s new here, you?re in for a treat. Apple's new and improved application crash management is well worth knowing about. Of course, in order to truly appreciate it, you have to get an application to crash. As this is not something you typically go out of your way to do, I?ll walk you through it all here.
Reopen and Try Again buttons
If you are familiar with the ?unexpectedly quit? dialog in Panther, the main difference you will notice in the Tiger version is a new button: Reopen.
As you might guess, clicking this relaunches the just-crashed application. If the application does not crash again, that's the end of things. You?re home free.
But if the application does crash again, the ?unexpectedly quit? dialog appears yet again - but with one difference: The Reopen button is gone, replaced by a Try Again button.
?What gives?? you may reasonably be asking at this point, ?What?s the big deal difference between Reopen vs. Try Again?? If you are more curious, another question may have occurred to you: ?How did Mac OS X track that this was the second time the application had crashed, so as to get the ?Try Again? button to appear??
Let?s start by answering the second question first:
When you select the Reopen button, Mac OS X adds a property to the preferences (.plist) file for the crashed application. It would not do this if you select the Close or Report button instead. It only happens if you click Reopen. These .plist files are located in the Library/Preferences folder of your home directory, with names like com.apple.Safari.plist. The added property is called ApplicationCrashedAfterRelauch and it will have a value of 1. You can most easily view this by opening the relevant file in Property List Editor (an application that is installed when you install the Developer (Xcode) software that comes with Tiger. Mac OS X checks for the presence of this property when an application crashes. If it is present, the Try Again button, rather than the Reopen button, appears.
[Note: Apple has changed the format of most of its plist files in Tiger. They are still XML files but they are now saved in binary format rather than text format. If you open them in Property List Editor they still open as a readable file, just as they did in Panther. However, if you open one in an ordinary text editor, such as TextEdit, it will no longer appear in easily readable XML formatted text. You can use Property List Editor to save a binary .plist file as a text file; it will still work but presumably with a slower performance. You can also still use the defaults command in Terminal to make changes to .plist files.]
This returns us to the first question: Why bother with this change at all? As it turns out, the change is significant because it is the visible indicator of something much more important that is going on behind the scenes. Here?s the scoop:
If and when you click the Try Again button, the application launches again. But this time, it does what Apple calls a ?safe relaunch.? In a safe relaunch, Mac OS X bypasses the use of the application?s .plist file. That is, all of its settings are ignored and the application opens with only its default settings.
This is the equivalent to manually deleting or disabling the application?s .plist file prior to launch. As regular MacFixIt readers know, disabling a .plist file is an commonly recommended procedure to solve trouble with an application. The .plist file may be corrupted. Disabling the file forces the creation of a new presumably uncorrupted default copy of the .plist file, thereby ?solving? the corruption problem.
What Apple does here is one better. It disables the effect of the file without moving it or modifying it in any way. It simply ignores it. If this indeed solves the crash problem, you will presumably select to quit the application normally at some point (by selecting the Quit command from the Finder). When you do, you will get the following dialog:
If you click No, the original .plist file is retained and will be active again on the next launch of the application. In addition, the ?ApplicationCrashedAfterRelaunch? property is deleted from the .plist file. This returns you to the state of affairs before all of this started. It also means that, if the .plist file was the cause of the crash, the crash will return as well.
If you click Yes, the ?ApplicationCrashedAfterRelaunch? property is also deleted from the .plist file. In this case, however, the file itself is renamed, with a .saved extension added to the end. Thus, a .plist file called com.apple.safari.plist would now be called com.apple.safari.plist.saved. This disables the .plist file without deleting it. The next time you launch the application a new default .plist file will be created. If the .plist file was the ultimate cause of your crash, the crash problem has now been eliminated. [Of course, the new .plist file will be missing any of your customized changes, so you may need to re-add them. If needed, you can still open the .saved file to see what they were.]
Overall, the effect is to automate just the sort of troubleshooting you had to do manually in Panther. Very cool!
Back to the initial ?unexpectedly quit? dialog, there is another button that I have not yet mentioned: Report. If you click this, it opens a separate dialog where you can enter details of your problem and view a console log listing of the crash. You can send this all to Apple. The dialog has been redesigned a bit in Tiger but otherwise duplicates the same feature in Panther.
Apple has included a surprise bonus for ?unexpectedly quit? dialogs in Tiger. After you install the Developer software, go to /Developer/Applications/Utilities. There you will find an application called CrashReporterPrefs.
If you run it, you will be able to choose from among three options:
- basic. This is the default option. The ?unexpectedly quit? dialog works as described above. Also, it appears only for standard applications (typically ones launched by a user).
- developer. With this option selected, the initial ?unexpectedly quit? dialog will contain a ?summary? of what is contained in the log file for the crash. More noteworthy, the dialog appears after crashes of system and background processes, not just after standard application crashes. Finally, an Attach Debugger button replaces the Reopen button. If you click this button, Terminal launches in a debugging (gdb) mode (this is of dubious value to any one but developers, in my opinion).
- server. With this option enabled, no dialogs appear after a crash, allowing for unattended operation on a server. Still, the crash reports are logged in the relevant crash.log files (accessible via the Console application).
All of these changes are accomplished by CrashReporterPrefs adding and/or modifying a property in the com.apple.CrashReporter.plist file (in ~/Library/Preferences). This is the preferences file for the Crash Reporter application (located in /System/Library/CoreServices), the application responsible for the Unexpectedly Quit dialog. When you select an item in CrashReporter Prefs, the DialogType property is modified to have a value of the category you selected (e.g., developer).
You may be aware that, in Panther, there were similar changes you could make to this .plist file. For example, adding a none property was similar to adding server in Tiger. These Panther options appear to still work in Tiger, although they are not included in the CrashReporterPrefs application.
This is the latest in a series of monthly mac.column.ted articles by Ted Landau. To see a list of previous columns, click here. To send comments regarding this column directly to Ted, click here. To get Ted's latest book, Mac OS X Help Line, click here.