Rss

Clanging away on the debugging chapter

Whew, another long stretch of radio silence on the blog, this time corresponding with my writing the debugging/performance chapter for the iPhone SDK book. It ended up running about 32 pages(!), because of the scope:

  • Build errors
  • Using documentation in Xcode
  • IB errors
  • Xcode debugger
  • Performance tuning with Shark
  • Performance tuning with Instruments
  • Static analysis with Clang

The last is a bonus topic that’s a bit of a risk, considering that we’re basically telling the user to download a nightly build, drop it in their /usr/local and try it out on their code.

I had the good luck to run the Clang Static Analyzer scan-build while my app-signing certificates were messed up, which totally failed and forced me to confront the realities of how it works: scan-build actually runs your command-line build script (either make or xcodebuild) and integrates into the gcc tasks of the build to do its work. If xcodebuild doesn’t work with your project’s default settings, you fail with an inexplicable error like this:

2008-10-15 15:58:33.461 xcodebuild[747:2a73] Warning: Couldn't discover the 'ccc-analyzer' compiler's built-in search paths and preprocessor definitions for language dialect 'objective-c'. This may lead to indexing issues.
Compiler: /usr/local/checker-109/ccc-analyzer
Reason: gcc-4.0: installation problem, cannot exec '/Developer/usr/bin/arm-apple-darwin9-gcc-4.0.1': No such file or directory

This turns out to usually be a total red herring. The problem in my case was that app signing was broken (I’d generated my new cert on the MacBook, and hadn’t exported my private key from that computer back to the Mac Pro), so the build was failing for code signing reasons. Of course, this would also happen for any of our readers who download a sample project where the default target is the device, if they either don’t have a certificate or haven’t changed the signing identity to something other than “iPhone Developer: Chris Adamson”.

Since we don’t really care about code signing or the device when we’re doing static analysis, the fix is to just go to the project’s properties and set the “Base SDK” to “Simulator – iPhone OS 2.1” rather than “Device”.

In other news, I still haven’t heard if I got my registration submitted in time to go to the iPhone Tech Talks in Chicago. Daniel says he registered for it too, so maybe we’ll road trip (or take a train, though the Amtrak schedules from GRR and K-zoo don’t fit real well). Also, check out the unintentional hilarity from Apple’s tech talks registration form:

If yes, what other mobile platforms do you develop on? Check all that apply.
Android
BlackBerry
BREW
Symbian
Palm
Windows Mobile
Other

Anybody notice a prominent mobile platform missing from that list? Like the one that everyone actually has on their phone, no matter how cheesy the model? I’m surprised the Java mob hasn’t blogged bitterly about this obvious example of nefarious skullduggery! and how much “Steve Jobs hates Java”. Actually, I think it’s quaint that they remembered that BREW exists. Or that Palm still does.

Comments (2)

  1. Ted Kremenek

    One minor clarification: the static analyzer does not need to be installed in /usr/local/bin. It actually does not care where it is installed. Users don’t even need to add it to their path. All the files they need come in a tar.gz file that can be extracted anywhere; if scan-build isn’t in your path, you can just invoke it directly:

    /fullpath/scan-build xcodebuild -configuration Debug

  2. Ted, thanks for the clarification. I’ll try to make it extra clear in the chapter that copying the checker-XXX directory to /usr/local and making a symlink to scan-build somewhere in your path is just a convenience.

    BTW, I also should note that the Clang Static Analyzer is crazy awesome. The point I make in the chapter is that it helps you find cases where your bugs aren’t as obvious as leaking thousands of objects in a tight loop, which is what I do in the Instruments section to show how to find leaks.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.