Debugging while driving
By seongbae on Mar 28, 2005
I carpool with a colleague who is an avid Apple user (he's got an iBook, an iMac G4 and an iMac G5, and an iPod 20G and an iPod Shuffle 1G). One day when we hop on my car to go home, he said his iCal hangs whenever he starts it...and that was the beginning of my first ever "debugging-while-driving" session.
He suspected his calendar data was corrupted, so he already tried backing it up and removing it. But that didn't fix the problem, so it wasn't the calendar data corruption. And he had no clue what other files iCal software accesses.
I've never used MacOS X before, so I had no idea what kind of system level debugging tools it provides, and my carpool buddy didn't use his Apple boxes for any software development so he was almost as clueless as I was.
However, my carpool buddy already found and had run some kind of "top"-like utility to see what processes are running and etc, and it showed iCal hanging.
The utility also allowed taking a snapshot of the stack trace for a brief period of time, and it showed truss-like output. He inspected the stack trace but didn't find anything interesting - there's no particular function that's at the top of the stack.
Being so accustomed to Solaris, first thing I liked to see was truss-equivalent but I nor my buddy didn't know the equivalent tool on MacOS X, if such a tool exists. While driving and having my buddy on the passenger seat with his iBook, I just asked him to try "ls \*trace\*" on a couple of usual places (/sbin /usr/sbin etc), and voila, there was an executable called "ktrace". A quick "man ktrace" confirmed that this was indeed what we wanted.
The next step was to find the iCal executable - fortunately, I used to run NeXTSTEP 3.3 on my university SPARC boxes (probably I was one of very few users of such systems in Korea at the time - there were handful of NS on Intel users
but NS on SPARC was...pretty much non-existent), and remembered that those \*.app was actually a directory containing bunch of different data/executable/etc for that application, and suspected that MacOS X uses the same scheme (btw, I've never used OS X before). The directory layout under \*.app sounded slightly different on MacOS X than on NeXTSTEP as my buddy read what he saw on the screen. But he found the executable under some subdirectory and fired the ktrace on it - and it hung as expected.
As is typical for any trace, the output was huge and my buddy couldn't figure the head and the tail out of it. I suggested to look at the files opened, especially the last file opened. The trace output showed some sort of XML based configuration file. My buddy backup the file and delete it, and started iCal and voila, it worked. Copying the file back to its original location, iCal hung again. It was a sort of configuration/option/preference file and was no big deal to start from scratch by setting the options in the iCal. We speculated that the file is corrupted, causing XML to be malformed or something similar, but didn't bother to investigate further - after all, my buddy was back to being a happy Apple user...and that was my first debugging-while-driving experience.