I know how to fix a Mac, now I need to know how to break one.

August 8, 2012 11:47 AM

How can I make a Mac app crash reproducibly with the solution being to trash the app's preferences and have them rebuild automatically?

I am setting up a technical test for someone, and I want to test their Mac troubleshooting knowledge. One of the most basic Mac troubleshooting steps is that if an app is having issues, delete or isolate the preference file(s) so they get rebuilt with defaults the next time you launch the app.

I'd like to set up a reproducible scenario like this, but the Mac apps I'm trying to break are much more resilient than I had hoped.

Does anyone know a way I can get an app to crash or have trouble repeatably that would be fixed by trashing the preferences?

posted by joshrholloway to Computers & Internet (6 answers total)

Rather than a crash how about an inability to save settings persistently? I'd try setting some files to read-only and see if you can get one to exhibit that behavior. Seems more likely to get you reproduceable behavior than trying to cause a crash.

That said, how are you corrupting the plist files? Seems to me your best bet is to use a hex editor to deliberately put the wrong type of data into a field or remove the field terminators. Using the Property List Editor will keep you from putting bad key type values.
posted by phearlez at 12:38 PM on August 8, 2012

if (somePreference) {
memset(0, 0, 1);
}
posted by tylerkaraszewski at 12:40 PM on August 8, 2012 [1 favorite]

What have you tried? Here are a whole bunch of ideas I haven't tried:

- unusable main window dimensions
- initial main window position that is outside of the screen bounds
- account with invalid password
- attempt to auto-load an unsupported file
- no read/write permissions on the prefs file
- changing the data type of the value (e.g. if it's supposed to be a bool, change it to an array)
- a non-parseable file (contents of /dev/random or /dev/zero)
- a zero-byte file
- a symlink to an unreadable location
- a symlink to a non-existent location
- permissions file owned by a different user
- symlink the prefs file to the app itself
- symlink prefs to a file in the trash
- prefs file is valid format but extremely large (2+ GB)

In my previous role, I interviewed a lot of software testers. I ended up writing a simple application that had several categories of known bugs. This was presented to candidates in the final minutes of the interview. Over time, it became less interesting to count how many bugs they found and in which category, and more interesting to hear them explain their approach and describe their findings. It was definitely a benefit to present the same problem to each candidate and directly compare the results.
posted by germdisco at 1:50 PM on August 8, 2012

Just in case you're not aware: as of Mac OS X 10.4 (so quite a while now!), the system will offer to temporarily do this for you if it detects an app repeatedly crashing in certain circumstances. More info here; this mechanism may have changed somewhat since, I'm not sure.
posted by glhaynes at 2:58 PM on August 8, 2012

Can you not just kill the process with SIGSEGV?
posted by TheNewWazoo at 8:58 PM on August 8, 2012

I'm not nearly as well-versed in OSX as I should be but why can't you just do something like manually corrupt the prefs files or save a copy of corrupted prefs before deleting them the next time the problem arises and then use those ones to "break" the computer when you need to?

This seems so simple that it has to be wrong.
posted by Gev at 5:31 AM on August 9, 2012