Archive for the ‘Apple’ Category

WWDC or bust

Friday, June 5th, 2009

Thanks to the generosity of Rogue Amoeba, the Ford Foundation, and listeners like you, I’ll be attending WWDC this year. If you want to find me there, I’ll be the one wearing a Rogue Amoeba T-shirt.

Actually, I’ll be one of the ones wearing a Rogue Amoeba T-shirt. The cute one.

No, sorry, that’s Paul. Let’s face it: in our fab four, I’m the Ringo. (Or for you younger folks, the Michael Anthony.) My plan is to earn millions hanging out with those other guys and making thumping noises in the background.

This will be my first time attending WWDC. I’m really looking forward to meeting fellow developers such as Rainer Brockerhoff and … umm … err … yeah. Anyway, hope to see you there!

To those poor, unfortunate souls who won’t be at the Moscone Center on Monday, I offer a consolation: the official 2009 WWDC keynote home game! The rules are straightforward. (1) Whenever Phil Schiller says something, drink. Heavily.

Radar Bug Friday: Bonus Edition

Friday, March 13th, 2009

Though Apple Bug Friday has gone the way of Rip and Robert Van Winkle, I’m bringing it back for one last, glorious, remunerative show. Opening act: some weird dancing fool who people last admired in the 80s. Take your choice.

The continuing failure of Apple to provide a searchable bug database has forced developers to take matters into their own hands. Witness Open Radar. I’ve never been one to join any club that would have me as a member — nor have I been one to be invited to any clubs — so I’ve decided to host my own list of bugs. Keep in mind that these are not all of the Radar bugs I’ve ever filed. They’re not even all of my currently unfixed bugs. They are, however, a very large subset of my currently unfixed bugs. (I’d say the cardinality is somewhere between aleph-null and aleph-one.)

For legal, moral, and comical reasons, I’ve edited the bugs to remove confidential information. I’ve also left out the embarrassing nude photos I attach for ADC. (I would stop uploading them, but engineering always requests more.) I hope that you find these bugs useful and also enjoy reading them as much as I enjoyed writing them. In fact, it’s a metaphysical certainty that you will enjoy reading them at least that much.

After imparting this vital information, I leave you to go in, through, and beyond … for coffee and a donut.

dSYM in your bundle or just happy to see me

Tuesday, January 20th, 2009

It’s been a while since I posted last. Rest assured that I did survive the Y2K9 disaster, though not unscathed. Since bloggers and other entertainers — such as Brian Williams — are required by law to offer a retrospective at the end of a year, I’ve been scanning the Top 10 lists of Top 10 lists of things that we have gained and lost in 2008. Next to our collective sanity, the most significant loss of the year was STABS. Actually, it wasn’t so much lost as deprecated. This means that we can’t expect any new features (or bugs!), and support for STABS debugging symbols may disappear in some future operating system, say, Windows -400. (I assume that the countdown of version numbers from 95 to 7 is intended to accurately represent the software’s regression.) In the transition from STABS to DWARF, it was thought (by the people who matter, viz., me) that we also lost the ability to ship debugging symbols with our apps. Luckily, it was discovered (again, by the people who matter) that we did not lose this ability.

Developers sometimes need to give users a debug version of an application. For example, a user may be experiencing an exception or crash that the developer cannot reproduce. Including debugging symbols with the app allows the reports to be fully symbolized. With STABS, the symbols reside within the app’s executable, so shipping them is trivial. The DWARF with dSYM format, on the other hand, puts the debugging symbols in a separate file. (To be accurate, a separate file within a separate bundle, but we’ll ignore that fact for this sentence.) By default, Xcode creates MyApp.app.dSYM in the same folder as MyApp.app, and indeed, Leopard’s crash reporter can locate MyApp.app.dSYM in the same folder as MyApp.app regardless of which folder they’re in on disk. Theoretically, then, you could have the user put a .dSYM in the same folder as the app. However, making the user do this would be, in a word, lame. In two words, pretty lame. Moreover, it doesn’t work at all on Tiger. Pretty, pretty lame.

When I face an insoluble problem, my tendency is to step back and get philosophical. Why do I exist? Why does the universe hate me? Who was the real Darrin? More to the point: what is an app? Essentially, an app is a command-line tool in a box with a pretty bow. (Another iSweater, just what I needed!) An app’s main executable file is located in the directory Contents/MacOS of the .app bundle. You can even launch an app from the command line, e.g.,

/Applications/Safari.app/Contents/MacOS/Safari

assuming that you haven’t deleted Safari for security reasons. So how does this information help us? It doesn’t — I’m just killing time here. However, it’s worth noting that if you build the Release configuration of a command-line tool project, Xcode by default creates MyTool.dSYM in the same folder as MyTool. In both Leopard and Tiger, the crash reporter can locate the .dSYM there. Thus, you would expect that the crash reporter can also locate MyApp.app/Contents/MacOS/MyApp.dSYM when your app crashes. And you would be right! (Of course, you would expect this because I just told you, whereas originally you would have expected to try a bunch of stuff and fail, like putting MyApp.app.dSYM in MyApp.app/Contents/MacOS.)

The beauty of this technique is that it works not only for the app’s main executable but also for other embedded executables such dynamic libraries and frameworks. When a crash occurs involving MyFramework.framework, the crash reporter will find

MyApp.app/Contents/Frameworks/MyFramework.framework/Versions/A/MyFramework.dSYM

You can build the framework in a separate Xcode project and copy the product along with its embedded dSYM into your app’s bundle, and the symbols will be found at crashtime. (That’s runtime with a bang.) In Tiger, the line numbers of the source code files can sometimes be a little off in the crash reports; this may be due to bugs in the handling of stripped binaries by atos, which I mentioned in my earlier post.

Now that we know where to put the debugging symbols in the app bundle, how do we get them there? Manual copying is unthinkable (like giving David Pogue a copy of OS X GM before ADC members, or putting Leon Panetta in charge of the CIA). If your entire build process is not automated, you should give up software development immediately and look for another career; I recommend professional ice dancing. You could write a shell script to copy MyApp.app.dSYM from the build directory, but that’s only slightly less annoying than having your users copy it to /Applications, because it’s something that Xcode should do itself.

Fortunately, the Xcode build setting reference tells us how to configure this. Or so one would think. Well, at least the relevant build settings are found in the environment variables … after you’ve written your shell script. The Xcode build transcript normally doesn’t show environment variables, but you can add a run script build phase to your target and check the option “Show environment variables in build log”. The environment variables reveal the default values for DWARF_DSYM_FOLDER_PATH and DWARF_DSYM_FILE_NAME, which Xcode uses in creating the dSYM file. Although you won’t find them in the target’s list of build settings, you can create them yourself in the User-Defined section. To embed the dSYM within the app bundle, just set DWARF_DSYM_FOLDER_PATH to $(CONFIGURATION_BUILD_DIR)/$(EXECUTABLE_FOLDER_PATH) and DWARF_DSYM_FILE_NAME to $(EXECUTABLE_NAME).dSYM. These settings should work for both apps and frameworks.

My beard has grown longer over the course of this post, and my knees are starting to ache, so it’s time to wrap it up, tip my hat to the new year, and meet the new boss.

Review of PGP boot disk encryption

Sunday, November 23rd, 2008

This is my first official software review. I normally don’t review software other than my own — Radioshift, five thumbs up, buy now! — because there’s no profit in it (like US auto makers). However, Dave Dribin asked me to do it, and apparently Dave gets whatever he asks for.

PGP Whole Disk Encryption introduced pre-boot authentication for Intel Macs in version 9.9. Pre-boot authentication allows you to encrypt your Mac’s entire internal hard drive. I wrote a form of whole disk encryption myself in Knox, but that was for non-boot disks. Prior to installing PGP 9.9, I had been using Apple’s built-in FileVault to encrypt the home directory of my MacBook Pro. I became interested in whole disk encryption for the laptop after I discovered that neither third-party developers nor Apple itself could be trusted not to write personal data outside your home directory.

This review is not intended to be comprehensive, because again, I’m not being paid for it … though if a certain corp whose name is a certain acronym would send a certain something my way, I would certainly be appreciative, wink, wink, nudge, nudge, say no more. Before you charge the software to Mr. Underhill’s American Express card (want the number?), I highly recommend that you study the user guide for important caveats. My aim is simply to describe my experience and to pass along some undocumented tips I picked up along the way.

I purchased Whole Disk Encryption for Mac, affectionately known as WDE4M, from PGP’s online store for 119 US Dollars (more than a bread box, less than a nano), and I received my license key by email within 10 minutes, so no problems there. It took slightly longer to encrypt my boot disk. The entire process required around 8 hours for the MBP’s 200 GB internal HD. (Actually, according to Mac OS X, it’s 186.3 GB. These are sometimes given the label GiB, which stands for Grrrr, ithoughtihadmore Bytes.) Obviously, you’ll want to let it to run overnight, unless you need a break from watching your grass grow.

In reviewing WDE4M, the first concern is security. When you boot your Mac from the internal drive, you get the PGP login screen. At this point, the Mac OS X volume has not yet been mounted. Until you enter your password at the PGP login screen, the entire boot volume remains encrypted. As long as you choose a good password (mine is Joshua), all of your data is safe. Note that it is still possible to boot your Mac from a different disk such as a DVD or an external hard drive. It’s even possible to boot into Firewire target disk mode (assuming you have a Firewire port: ha, ha!). However, you won’t be able to mount the Mac OS X volume on the internal drive, because without PGP running, you have nothing more than a partition full of encrypted bytes. Indeed, PGP modifies the partition table of your disk to add its special boot partition, so I would recommend starting with a single volume of data. I previously had multiple partitions and volumes on the MBP, but I found that to be a PITA regardless of PGP.

After you authenticate successfully at the PGP screen, the computer boots normally into Mac OS X. It is crucial to realize that when you’re booted into Mac OS X, your data is vulnerable. PGP will decrypt on the fly any bytes that the OS asks for. Thus, if someone steals your laptop while it’s running OS X, you’re screwed. You can try logging out or setting a screensaver password, but those types of protection can often be defeated. The only way to guarantee safety is to shut down or reboot. Thankfully, WDE4M protects against so-called ‘cold boot’ attacks (unlike FileVault).

The next issue for WDE4M beyond security is performance. On my MBP with a 2.33 GHz Intel Core 2 Duo and 2 GB RAM, I’ve found performance to be a non-issue. Admittedly, I’ve never done speed tests, but I don’t perceive my system to be sluggish or slower from PGP WDE. It seems as ZippyTM as ever. I’ve heard from some sources (e.g., the shoe shine guy) that PGP’s encryption / decryption is much faster than FileVault’s. The only operations that seem a little slow are copying extremely large, multi-GB files from another disk; the entire contents of these files must be encrypted as they’re copied onto the internal drive.

The final issue I’ll discuss is backups. If you care about your data, you must back it up, otherwise you will lose it at some point. If your data is important enough to protect with WDE4M, it’s important enough to back up. (Note that I made two full backups of my internal drive before attempting to encrypt it. I also downloaded my brain into an android.) No backup strategy is perfect for everyone, so we must each follow one that fits our needs. For example, the majority of computer users follow the strategy that experts term ‘Divine Intervention’. I had to experiment quite a bit before I found something that worked for me: in the end I turned to good ol’ dd.

My procedure for backing up my PGP-encrypted internal hard drive is simple. Even a caveman could do it. (Yes, Unix has been around that long.) First I mount an external backup drive that has enough free space to fit my entire internal drive. Then I boot into the Mac OS X installer: this can be done from a partition on the external drive, from a DVD, or from a USB stick. A Mac OS X installer volume is not required to perform the backup — you could use another Mac, for example — but I use an installer so that I can boot from the MBP and take advantage of its Firewire 800 port. Finally I launch Terminal and enter the following:

dd if=/dev/disk0 of=/Volumes/backups/disk0.dmg

Running dd takes 5 to 7 hours back up the MBP’s 186 GiB HD to a FireWire 800 external HD. I might be able to expedite the process by tweaking the bs operand of dd, but I’m running the backup overnight anyway, so I favor simplicity and reliability over speed. Afterward, I have a byte-for-byte backup of my entire internal drive. Any machine running PGP can mount the dmg with the correct password, so the backup is suitable for file-based restoration. A machine without PGP installed, in contrast, will fail to mount the dmg, finding no mountable file systems, because the entire file system is encrypted.

From a security standpoint, a byte-for-byte backup is not ideal, because it has the same encryption key as the original. Once you start modifying files on your internal drive again, it’s conceivable that a diff between the backup and original could reveal something interesting. However, few people in the world have any hope of success in extracting readable information through such an investigation, certainly not the casual thief, and of course backing up your files unencrypted would be infinitely worse! I’m not trying to keep any state secrets (my WMD is curled up sleeping on his cat bed), but if you’re the paranoid type — and my hidden video cameras show me that you are — you should be able to encrypt your backup drive with a different key before you create the dmg with dd. Indeed, you could create one big encrypted dmg with Disk Utility and put the backup dmg inside it. I haven’t tried this myself, so I’d be interested to hear whether it’s viable. Anyway, this Russian doll approach would provide ample protection if your data were stolen by the Russian mafia, or if you were a member of it.

In the event of catastrophic data loss, e.g., my laptop is swallowed by a whale, I can use the backup to easily transform some other disk into a bootable clone of the laptop:

dd if=/Volumes/backups/disk0.dmg of=/dev/disk1

If you have an external drive the same size or slightly larger than your internal drive, you can skip the dmg and create a bootable clone directly:

dd if=/dev/disk0 of=/dev/disk1

The disadvantage of this procedure is that any extra space on the backup drive would be unusable. I have a few 500 GB (465 GiB, sigh) external HD’s, so it makes more sense for me to save multiple backups on each drive.

You can boot a clone of your PGP-encrypted drive from another machine regardless of whether the machine has PGP installed on its internal drive. However, it may take a couple of spontaneous reboots before you can login to Mac OS X, much like a software update, so you need to be patient. (Perhaps it’s updating the boot cache?) Also, booting the clone from the original machine is to be avoided. As a test of my backup procedure, I cloned my MBP to an external drive and then booted the MBP from the clone. The MBP did successfully boot from the external drive, and I was able to login to Mac OS X, but I was surprised to find that the Mac OS X volume was mounted from the internal rather than the external drive. This bizarre behavior puzzled me until I read Secrets of the GPT, which I already mentioned in my last post. The technical note warns, “Be careful when doing a block-for-block copy of a GPT disk. The GUID in the partition table header that identifies the disk (and the GUIDs in each partition entry) are meant to be globally unique, and Apple’s system software relies on this feature.” If you do what I did, “the computer might boot from either the original or the copy in an unpredictable fashion (perhaps toggling from boot to boot).” Oops! That reminds me of the time I got mount to show two volumes with the same BSD name … but that’s a tale for another day.

WDE4M comes with PGP Desktop, which has a number of useful features such as handling public-private key-pairs and allowing encryption of AOL Instant Message sessions between PGP users. PGP Desktop can automatically encrypt email as well, but one thing to look out for is that it attempts this by default. I kept getting “Invalid Authentication Certificate” warnings in Mail.app, and I initially blamed this on Leopard, because the warning window did not indicate that it was from PGP, and I had just installed Leopard prior to installing PGP. You can turn off the email encryption feature in the Messaging Security preferences of PGP.app. Hopefully PGP will put its name on the warning window in the next software update to PGP 9.9, so that it’s clear to the user where the warning is coming from.

Overall, in summary and conclusion, to wrap it all up, finally: I find WDE4M to be a well-engineered product, it does what it’s supposed to do, viz., protect all of your data, I have no regrets about buying it, and I have no reservations about encouraging other people to buy it too.

P.S. If you like WDE4M from PGP, you might also enjoy Airfoil from Rogue Amoeba. Nudge, nudge, say no more.

What about Sony?

Sunday, November 2nd, 2008

Yesterday I purchased an 8 GB Sony Micro Vault USB drive.

USB drive

I’m sure it’s a fine device, though it’s far too early at this point to comment on its functionality. What I found immediately noteworthy was the packaging.

The drive came encased in a hard plastic tomb roughly ten times its size.

Front of package

Why such a large package for such a small item? The answer lies on the back.

Front of package

Not an inch to spare! Clearly, the size of the package was justified by the need for operating instructions on the back. Or important warnings before use. Or something? Actually, it’s not clear at all, because the font is ridiculously tiny.

If we take a close-up, we can see that the text does indeed provide us with instructions and warnings…

Front of package

…for opening the package. In seven languages, no less. And what do those instructions tell us?

Use scissors.


Postscript: You would think that finding the right storage size for your needs would be easy. The Finder told me that the files I wanted to put on the USB drive were 7.1 GB. Thus, an 8 GB drive should be plenty big. Right? Right?

For some reason that escapes me and that has somehow, astonishingly, escaped class action lawsuits, the drive manufacturers and the operating system manufacturers count GB differently. The capacity of my Micro Vault is 8,019,509,248 bytes, which according to Sony is 8 GB but according to Apple is 7.5 GB. Well, ok, so I lost half a gig right out the box, but I still have more than I need. Right? Right?

The USB drive came with a Master Boot Record partition scheme for Windows machines. This was no good for my purpose, because I was going to boot Intel Macs from the drive. Thus, I repartitioned in Disk Utility with a GUID Partition Table scheme, which is used by Intel Macs. When I was done, I was shocked to discover that the drive now contained less free space than I need for my files! What happened?

The answer can be found at Secrets of the GPT. Apple considers my USB drive to be a “big disk”. (Have they seen the photo above?) As a consequence, they ignored my choice of one partition in Disk Utility and added a second, 200 MB partition on the drive for EFI device drivers, although Apple does not currently use it for anything. Moreover, they added 128 MB of empty space after my main partition to make it easier for future system software to manipulate the partition map in ways that we can’t anticipate currently. That’s great for my great-grandchildren, but at present, I want that space.

My workaround for the problem was to reformat the drive using an Apple Partition Map scheme. This takes up less space on my “big disk”. Although APM is used by PowerPC Macs, it turns out that Intel Macs can boot from an APM drive too.

If APM didn’t work, I was going to use scissors.

Working without a nib, Part 7: The empire strikes back

Monday, October 20th, 2008

I recently received an email from Steve Jobs. He told me that he has read all of my blog posts. I found this ridiculous, so I replied, “You’re full of it!” Shockingly, he wrote back. “Actually,” he said, “all of the new apps of the past few years are nibless.” He then described the Apple-sanctioned technique of writing a nibless application.

In previous posts of this series, I was forced to use obscure workarounds such as +[NSObject poseAsClass:] and method_exchangeImplementations() to prevent NSApplicationMain() from trying to load a nib. Jordy Rose of Belkadan Software suggested to me that the easiest way to prevent NSApplicationMain() from trying to load a nib would be to avoid calling NSApplicationMain() at all. Instead, you would just call -[NSApplication run]. However, I was worried that NSApplicationMain() might do something else important (like phone home to get permission to launch). We don’t know, because we don’t have the source code.

I’m still waiting for the source code, but Steve did indicate that it was safe to skip NSApplicationMain(). Thus, there’s no need for tricksy runtime manipulation, except perhaps to prove your mad programming skills. Mad, that is, in the sense of having worn one ring for too long. Steve also affirmed that our call to -[NSApplication setAppleMenu:], a method that Apple removed from the API, will continue to work until there’s a replacement API. Indeed, Apple is working on some kind of replacement. Excellent! /me plays air guitar. So if you’re counting at home, it’s now (1) Exchange support and (2) Nibless support.

He didn’t mention the Open Recent menu, so it appears that my ugly hack is still required for non-document-based apps. This cannot be considered part of the Apple-sanctioned technique, though it is sanctioned by me, which is more desirable, because my approval comes in seven delicious flavors. I’ve updated Nibless for Leopard in light of Steve’s revelations and am making version 2.0 available for immediate download. This is major progress, because it already puts me two versions ahead of VLC.

So long, Steve, and thanks for all the fish!

I’m a Rogue

Saturday, June 7th, 2008

I’m delighted to announce that I’ve been hired as Rogue Amoeba Employee 008. (Employee 007 is Longwell, Justin Longwell.) I’ll be working on Rogue Amoeba’s apps as a software engineer, as well as providing comic relief. Thanks to Alex, Paul, and Quentin for this once-in-a-lifetime opportunity. My coworkers at Rogue Amoeba Software, LLC include fellow bloggers Mike Ash and Guy English. Together we form perhaps the most talented group of Mac programmers outside of Apple. (Yes, I’m talking to you, Adobe and Microsoft.) Indeed, I haven’t seen such an array of stars in one place since the Ghostbusters music video.

I’ve joined Rogue Amoeba just in time to miss WWDC ’08. In an earlier post, I mentioned that I left Marko Karppinen & Co. LLC just in time to miss WWDC ’07. (I’ll make it there someday! :-( ) The question is, what have I been doing in the meantime? Backpacking through Europe? Rotting in Gitmo? Running for President? No, I’ve been working on super-secret projects for Francis Technical Services, LLC. Although FTS is a little-known company, its software is well-known, at least inside Apple. For example, FTS is responsible for Radar, the Apple-internal Cocoa app that opens when employees click on the funny-looking rdar://problem/ URLs you often see. The number at the end of the URL corresponds to the problem ID of the bugs you file on the web with Apple Bug Reporter (also known as RadarWeb). It’s useful to have one of these URLs available when communicating with Apple engineers, because their managers forbid them from lifting a finger without a Radar problem number.

While at FTS, I did some bug analysis for Radar: that is, analysis of bugs in Radar’s source code, not analysis of bugs in Radar’s database, to which as a contractor I had extremely limited access. However, I mostly worked on other projects, such as Radar’s sibling app Sonar. Apple’s DTS uses Sonar to communicate with ADC members (such as me!). If you’ve ever seen sonr://request/ URLs — the Mighty Quinn provides one in an Apple Mailing List post — those open in Sonar. (By the way, I’ve read all of your emails to DTS. No, you haven’t been accepted to the iPhone Developer Program. Stop whining.) Another project that I worked on was Merlin, an app for Apple’s Human Resources department. I think that Steve Jobs is doing an outstanding job at Apple, so before I left I used Merlin to double his annual salary.

I’d like to thank Dave Francis, the owner and founder of Francis Tech, for the opportunity to work there. Despite appearances, I’m not really the type to hop from job to job. I’ve just been looking for Mr. Right, LLC, a company to fall in love with, marry, and have baby apps with. (As for any other support claims, sorry Billie Jean.) I can see myself growing old with Rogue Amoeba. (Easy to see when you’re already old?) Besides, someone has to stick around and keep an eye on mikeash, stop him from taking over the world.

Now without further ado, please take out your credit card and buy some of our fine software. As a special bonus for our Leopard customers, your purchase will be (code-)signed by your favorite Rogue Amoeba star.

Vienna not dead yet, but RIP Panther

Sunday, June 1st, 2008

Alas, poor Panther! I knew him, Horatio. You, Horatio, I don’t know so well, and you’re creeping me out. Why did you bring me to the cemetery?

The good news is that the first beta version of Vienna 2.3.0 is now available for download. Actually, it’s more of a zeta version, if you know what I mean. (You don’t.) The changes from 2.2.2 are listed in the release notes. The bad news is that Vienna 2.3 won’t run on Mac OS X Panther. Vienna 2.2.2 is the last release that supports Panther. That sucks, but if you’re still running 10.3.9, you probably don’t care much about the latest and greatest software anyway. Vienna 2.2.2 will continue to be available at Sourceforge.

Yeeha, Jester’s dead! I am dangerous, ice man.

SECURITY ALERT: Mac OS X 10.5.2 subverts FileVault

Saturday, May 10th, 2008

I apologize for not posting this earlier. I’ve been extremely busy lately, and I had discussed the issue with someone who said that he or she (he) was going to post about it (but hasn’t).

The security alert is for FileVault users running Mac OS X 10.5.2. You thought that FileVault encrypted your personal data, right? Wrong! In Mac OS X 10.5.2, the location of the CFNetwork caches was moved from ~/Library/Caches, which is within your home directory and thus encrypted, to /private/var/folders, which is not within your home directory and thus not encrypted. This means that anyone with physical access to your hard drive could, for example, determine which URLs you’ve loaded, even if your computer is shut down.

Note that nothing about this change was mentioned in the Mac OS X 10.5.2 release notes.

For further reference on this issue, see the thread that began in the WebKit SDK mailing list and was moved by me to the Macintosh Network Programming mailing list. Thanks to Eric Long, who noticed the change in the first place, and Ron Hunsinger, who performed testing that I was too lazy to do. (In my defense, I haven’t yet migrated my FileVault account from Tiger to Leopard, so the issue doesn’t affect me directly.)

Stabs is deprecated

Sunday, March 9th, 2008

This post is dedicated to E. Gary Gygax, the second greatest corrupter of youth in history. It’s about D&D, that is, DWARF and dSYM. As of 2008-02-27, the STABS debugging symbols format has been deprecated by Apple. The default value for the DEBUG_INFORMATION_FORMAT build setting in Xcode projects had been stabs, but now it’s time to move on. (I’m talking to you, Justin Long.) Our other options are dwarf or dwarf-with-dsym. Also cake or death.

With STABS, you could build the release version of your app with debugging symbols, make a copy of the executable MyApp.app/Contents/MacOS/MyApp to keep, strip the executable for shipping, and then use the unstripped executable for symbolizing crash reports by giving a space-separated list of stack trace addresses to the command-line tool atos. Unfortunately, atos cannot currently serve this purpose with DWARF. Unlike STABS, DWARF does not include the debugging symbols in the executable itself but merely includes references to the intermediate object files, which do contain debugging symbols. You can usually find these .o files in a sub-directory of the build/MyApp.build directory. If you delete the object files after building with dwarf, you won’t be able to step through your app’s code. (With stabs, the object files are refuse.) You also won’t be able to step through the code if you strip debugging symbols from your app, even if you keep the object files, because the references to the object files will be gone from the executable.

To avoid losing the debugging symbols for your app after stripping, you want to use the option dwarf-with-dsym. The DWARF with dSYM option performs an additional step beyond ordinary DWARF: it creates a separate MyApp.app.dSYM file that contains all of the debugging symbols for your app. In fact, the DWARF with dSYM option allows you to step through your code regardless of whether the executable is stripped! This is possible because gdb will look for the .dSYM file in the same directory as your app. It doesn’t need to know the name or location of the object files. If you don’t strip debugging symbols, you can use either the .o files or the .dSYM file for debugging, but for the local debug build of your app there’s no point in using dSYM, since that would just prolong your build time. You have better things to do than wait for builds, such as writing comments on Slashdot.

The trouble with atos is that it does not reliably find debugging information in .dSYM files for stripped executables. Although Apple’s documentation (as of 2007-04-02) says, “If you’re using DWARF dSYM files, you must be using the version of atos included in Xcode 3 (Mac OS X version 10.5)”, Apple’s engineers say, “The underlying framework that atos uses doesn’t support loading symbol names from dSYM files in Leopard.” In my testing, however, there doesn’t seem to be a difference between Leopard and Tiger, at least not with Xcode 2.5 on Tiger. On both Leopard and Tiger, atos successfully loads symbol names from .dSYM files (I deleted the .o files) for unstripped executables. For stripped executables, in contrast, atos frequently fails to load the symbol names, or even gives inaccurate results.

The CrashReporter Technical Note suggests loading your app and its .dSYM in gdb to translate stack trace addresses from crash reports. That’s like having to start your car in order to read the odometer. (Oh wait, I have to do that, Nissan!) An alternative method is the command-line tool dwarfdump. It requires only the .dSYM file, not a copy of your app, and its --lookup option will do the same job as gdb without the overhead.

Please note that by breathing, blinking, or moving at all, even to command-w this page, you thereby register your agreement not to disclose or discuss this information anywhere with anyone at any time, no matter the duress, torture, or water-boarding you may undergo to extract it. This agreement holds despite the fact that the information is publicly available on the internet for every person in the world to read. Failure to uphold this agreement will result in multiple, painful cat scratches, in certain cases leading to cat scratch fever.