• On TV.com: TOP 10 Shows CANCELED Too Soon
advertisement
May 12, 2005 7:30 AM PDT

mac.column.ted: Tiger's new and improved ?application crash? dialogs

by CNET staff
  • Font size
  • Print
  • 15 comments

Ted Landau
May 2005

[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!

Report button

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.

CrashReporterPrefs

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.

Resources

  • More from Mac Musings
  • Recent posts from MacFixIt
    iTunes 9.0.3 breaks AirTunes connection for some
    Apple releases Aperture 3.0
    Manage iCal's automatic e-mail generation for invitations
    CNET TV Apple Byte: Apple faces critics
    Weekly Utilities Update: Net Monitor, MiniUsage, TimeMachineEditor, more...
    Odds and Ends: Essential video codec packs for OS X
    Address Book: Unable to add, view contacts
    Persistent 'Faster Browser Search' overtaking Safari's default search
    Add a Comment (Log in or register) (15 Comments)
    • prev
    • next
    by Angostura-3 May 12, 2005 8:18 AM PDT
    The daft thing is, anyone 'kind' enough to report the issue to Apple will never
    get a chance to benefit from the troubleshooting tool.

    What is needed is a 'Report and then launch again' button or somesuch.

    Or a 'Try again' button in the crashreporter.
    Reply to this comment
    by JKT May 12, 2005 8:19 AM PDT
    One issue with this much improved crash reporting is that there is no way to
    save the info for
    later sending while you are offline. You can leave the window open, but if you
    logout/shutdown it is lost. The crash log can be recovered from console but
    the added info (what happened, what you were doing etc) inputted by the
    user is not saved.
    Reply to this comment
    by ether--2008 May 12, 2005 9:45 AM PDT
    The thing I don't understand is why there isn't a "Send the crash report to
    someone _other_ than Apple" option. I'm sure that Apple doesn't want to see
    the crash reports for MyFlakeyDevelopementProject.app, but I'd love to be
    able to send them to the rest of my team by clicking a button and putting in
    an email address, instead of manually cutting and pasting the contents of the
    crash box to a message.
    Reply to this comment
    by draccy May 12, 2005 9:45 AM PDT
    >
    This is a reply to a previous comment by ether--2008


    I always wondered about that. When I run an application that crashes frequently on my system (such as the shareware app Sound Studio), should I bother sending the crash reports to Apple? Does Apple just toss them out? Why does it even offer to send reports about non-Apple apps?

    What would be cool is if Apple had a developer registry so that developers could have crash reports automatically routed to them without the user having to know the difference.
    Reply to this comment
    by Doug Metz May 12, 2005 9:45 AM PDT
    >>
    This is a reply to a previous comment by draccy


    As to why it offers to send to Apple:
    I've noticed that Unexpected Quits do not always offer to send a report to Apple,
    so I was thinking it knows when that's appropriate. Haven't checked it out,
    though.

    As to sending information without user knowledge:
    Not allowed. Has to be user option... maybe another preference.

    Doug
    Reply to this comment
    by awoolman May 12, 2005 9:45 AM PDT
    >
    This is a reply to a previous comment by ether--2008


    Got to be possible, as Golive CS2 has crashed on me a few times, and the
    window said "Send report to Adobe", which I did.
    Reply to this comment
    by Mark Douma May 12, 2005 9:45 AM PDT
    >>
    This is a reply to a previous comment by awoolman


    What you saw was actually Adobe's own crash reporter application, not the one
    built-in to OS X. It's made to look similar to OS X's though.
    Reply to this comment
    by buttoncat_dotmac May 12, 2005 2:08 PM PDT
    TIME SENSITIVE - Can you re-title the article before more damage to Apple's
    reputation has occurred?

    The title is too ambiguous - it is highly visible in the articles list, and it sounds
    like Apple's new application crashes!

    Thanks.
    Reply to this comment
    by captrobt May 12, 2005 2:08 PM PDT
    >
    This is a reply to a previous comment by buttoncat_dotmac


    That's what I thought too! It sounds alarming - like "Apple's new application"
    was crashing.
    Reply to this comment
    by mrbach2 May 12, 2005 2:08 PM PDT
    >
    This is a reply to a previous comment by buttoncat_dotmac


    Why change the headline to help Apple? I have never had so many of these crash
    dialogues until 10.4 was released. The OS has major problems juggling CPU
    intensive tasks, especially when Java programs are running. Dashboard spikes
    processor use when it comes up and I wish Apple had given us the option to
    force quit this monster.
    There isn't enough complaining going on. Spotlight needs an off switch!
    Reply to this comment
    by Doug Metz May 12, 2005 2:08 PM PDT
    >>
    This is a reply to a previous comment by mrbach2


    Have you tried dragging your whole drive into the 'Privacy' list?

    Doug
    Reply to this comment
    by Rosyna--2008 May 12, 2005 5:57 PM PDT
    I just got a kernel panic for some odd reason and when I rebooted I was
    presented with this happy dialog:

    http://
    unsanity.org/rosyna/imgs/macosxquit.png
    Reply to this comment
    by klktrk May 12, 2005 8:53 PM PDT
    Boy,in the last few years, Apple's interface standards have gone steadily down hill. Are they drunk over there? Is anyone paying attention?

    Look at those dialogs. The first one, the farthest right, default button is "Reopen", in blue.

    The second time the application crashes, the BUTTON HAS MOVED! That's such a basic no-no in interface design, I don't know whether to laugh or cry. Add to that that the button that is now in its place has the word "Report" on it, which shares the first two letters of "Reopen" which means that at first blush, it's going to look like the same button as before. Most users will click Report, thinking they're clicking "Reopen" simply because it's blue, in the same place, and starts with the same first letters as the button that was there before. Come on Apple!

    Then, of course, add to that the odd choice Apple made, as has been pointed out above, to NOT let a user who chooses to report the crash avail him or herself of the troubleshooting functionality that this dialog ostensibly provides. No, if you report to Apple, you don't get to keep your comments, and you don't get to reopen the application with new, clean, default preferences.

    It's another example of a good idea executed in laughably poor fashion... much like spotlight, but if I get started on that, I'll run out of my harangue-ing quota for the day :-)
    Reply to this comment
    by Doug Metz May 12, 2005 8:53 PM PDT
    >
    This is a reply to a previous comment by klktrk


    I agree 100% on your interface observations.

    However, I am Really Loving Spotlight. Sorry it's giving you fits, but mine's
    working GREAT!

    Have you tried a fresh re-index? <ducks>

    Doug
    Reply to this comment
    by timstree_dotmac May 16, 2005 7:52 PM PDT
    Sorry, I was confused about the title too... I thought it was referring to Tiger
    Direct.
    Reply to this comment
    (15 Comments)
    • prev
    • next
    advertisement

    About MacFixIt

    MacFixIt is CNET's troubleshooting resource for all things Mac. The information here helps you navigate the ins-and-outs of Mac ownership with how-tos, troubleshooting information, news, reviews, and more.

    Add this feed to your online news reader