Debugging while driving

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.


Good one, how long is your drive?

Posted by Mark Linn on March 31, 2005 at 09:42 AM PST #

30 minutes or so. Depending on the traffic, of course. For those of you living in the Valley, it's from Menlo Park to Almaden Valley in San Jose.

Posted by Seongbae Park on April 04, 2005 at 10:49 AM PDT #

Hehe - the ironic thing about that is that I always get annoyed when I'm facing some problem with OS X and a user tells me to trash the plist file (the name for the XML property list thingy - they used to be binary things like serialised C structs in NeXTSTEP). This is one of those cases where it actually works :-)

Oh, and I also wanted to join you in NS3/SPARC solidarity - OK, I'm not in Korea but my network (undergrad computing lab.) has two SPARC 5s running NS3.3. The network was fully NeXTSTEP on black,SPARC,Intel up until about 2000. I took it on last year and it's currently a mix of Solaris, OS X and NeXT.

Posted by Graham Lee on April 07, 2005 at 09:29 PM PDT #

Please tell me which xml file it was that was hanging. I've got the same problem :(

Posted by John Borwick on September 27, 2005 at 10:21 AM PDT #

Post a Comment:
Comments are closed for this entry.



« July 2016