Debugging iPhone Crashes

Sometimes, developing iPhone applications can be very frustrating. Debugging crashes and memory issues can be very time consuming if one does not know how. Unfortunately, most books on iPhone programming either devote less than a chapter on debugging or, in most cases, totally skip it.

This post tries to de-mystify debugging crashes. When I say crashes, I mean straightforward exceptions (and not the memory access errors).

Typically, release builds are stripped of debug symbols to prevent reverse engineering (and other kinds of 'abuse') and to keep the released binary small in size. But, by doing so, you end up with only bunch of cryptic addresses in the log and absolutely no information on where the problem is (unlike in Java stack traces which pin-point the source of the exception).

On iPhone, typically, when the application is built, in the build folder (where the .app file is located), you will also find a file with a '.dSYM' extension, that contains a copy of the symbol information in the executable. This file maintains a one-to-one relationship between the source code and the compiled object code, which could make it possible to correlate an execution address with a line of code in the original source. I found that .dSYM files are generated by default. But it is a good idea to check your project settings in Xcode and ensure that 'Generate Debug Symbols' is checked.

Next, grab a copy of ratos. ratos is a ruby script that symbolicates the entire stack trace using atos (address to symbol) tool. The script is very simple to use and extremely helpful. Here is a sample output:

App Name:AtosDemo
App Path:/Users/ajeya/Documents/workspace/AtosDemo

Paste xcode stack trace to stdin, then type 'sim' or 'arm' on a line by itself.
Type 'exit' or '^D' to quit and 'app' to print the current app.

ratos>Stack: (
2483900683,
2534657595,
2483900139,
2483900202,
2478626815,
2478092680,
10809,
816608399,
10391,
816111650,
816149355,
2478330414,
2483403557,
2483403992,
827745792,
827745989,
816114848,
816160924,
10308,
10162
)
sim

-[AtosDemoViewController viewDidLoad] (in AtosDemo) (AtosDemoViewController.m:36)
-[AtosDemoAppDelegate applicationDidFinishLaunching:] (in AtosDemo) (AtosDemoAppDelegate.m:21)
main (in AtosDemo) (main.m:14)
start (in AtosDemo) + 54

Detailed instructions on how to use the script can be found on the script's homepage.

Of course, you can also choose to use 'atos' directly. But, I found ratos to be much more convenient.

Here are some useful links on debugging on iPhone and Xcode:

1. ratos source on github
   
2. Symbolification
3. Debugging and Symbolizing Crash Dumps in Xcode
   
4. Stacktraces
   

Wolfram Alpha

The much awaited (and a bit hyped) Wolfram Alpha made its debut last week. There was a lot of talk about it being a Google killer and like everybody else I too wanted to try it out. But I was in for a surprise. Firstly, Wolfram Alpha is NOT a search engine. It is being touted as a 'computational engine' which uses an internal knowledge base and outputs computations. Confused? I was too.

My first query was for 'iPhone' which did not return anything. Next, I tried Apple and I was presented with a lot of information about Apple's stock. Information included the latest stock price, revenue, price history, performance comparisons and a lot more. I was slowly getting a gist of what it does. Next I searched for '1 USD in INR' and got some interesting results.

I, then, tried other searches like 'Hyderabad', my birth date and anything else I could think of and there were some interesting and some not so interesting nuggets of information I gathered.

So, my take on the whole thing is that Wolfram Alpha is a data aggregator. Unlike Google, they don't use the internet as the data source and rely on their own internal knowledge base. Only time will tell how effective this tool is and whether or not regular netizens will adopt this tool. I, for one, need to find a reason to use this.

You can register for application APIs here and can find the FAQ here.

Static Code Analysis with 'clang'

On Leopard, all Cocoa objects are garbage collected, the developer has the luxury of not having to worry about memory management and can let the system take care of it. There is no such luxury on iPhone since garbage collection can be a performance intensive process. So, it is possible for memory leaks (and other nasty bugs to creep into the code during development). There are a bunch of tools at the developer's disposal to identify such problems and fix them. One such tool is the 'clang' analyzer.

I have found static code analysis to be an indispensable tool when it comes to discovering some very common bugs early in the development cycle. I first heard of the LLVM/Clang static code analyzer command line tool for Mac/iPhone late last year but started using it only recently.

The best way to understand how this works is to look at an example. The following is a sample code containing some obvious (and some not so obvious) memory leaks and bugs:

- (void)viewDidLoad {
  // Uninitialized object
  NSString *string1;
  
  if (NO) {
    string1 = [NSString stringWithString:@"Foo"];
  }
  
  NSUInteger counter = 0;
  
  NSNumber *number = [[NSNumber alloc] initWithInt:0];
  if (YES) {
    // Memory leak
    return;
  }
  [number release];
}

- (IBAction)createString:(id)sender {
  // Memory leak
  NSString *foo = [[NSString alloc] initWithString:@"Foo"];
}

- (NSString *)dummy {
  NSString *string2;
  return string2; // Returning an uninitialized object.
}

The analyzer can now be invoked simply by executing the following from the command line:

scan-build -k -V xcodebuild -configuration Debug -sdk iphonesimulator2.2.1

scan-build is the script for running the analyzer over a project build. The above example assumes that scan-build is in the path. The '-k' flag forces the script to keep going even if there are problems in compiling some source files and '-V' flag runs a small web server and opens up the results file in a browser. Running the analyzer against the above code, detected 5 bugs.

The analyzer works best with 'Debug' builds. The tool is not perfect and does throw up false positives, but in most cases it is bang on target. The tool also does not catch some slightly more difficult to detect leaks, but more about that in another post.

LLVM/Clang Mac binaries are available on the home page.

Why So Serious?

I decided to start posting all the non-tech related, fun stuff to my new blog. Keep checking it out for some interesting posts :-).

Best Beatboxer!!!

This guy is insane!!