In Objective-C, all objects (derived from NSObject) have a description method, which returns an NSString describing the object. When using GDB, you can print the description using print-object, for example, let’s use the interface definition below to look at a few descriptions:

@interface SandboxViewController : UIViewController <UITextFieldDelegate>
{
  UITextField  *username;
  UIButton     *testButton;
  UILabel      *label;
  UIView       *view;
}

When stopped on a breakpoint in the SandboxViewController object, GDB can display information on each object:

Note, po is equivalent to print-object.

Print-Object and recursiveDescription

When working with UIView objects, there is an additional method for obtaining information, recursiveDescription. When using print-object and calling this method you can see the entire view hierarchy for the object.

With the SandboxViewController object defined above, in the loadView method I created a UIView as follows:

[self setView:[[[UIView alloc] initWithFrame:[[UIScreen mainScreen] applicationFrame]] autorelease]];

Within GDB, when on a breakpoint within the SandboxViewController object, I can now view the entire view hierarchy as follows:

The same idea works for a UIView that is not associated with a view controller. Using the view defined below, and the label added as a subview:

// Create UIView
view = [[UIView alloc] initWithFrame: CGRectMake(10, 10, 300, 50)];
[[self view] addSubview:view];
 
// Add label to UIView
UILabel *tmplabel = [[UILabel alloc] initWithFrame:CGRectMake(10, 20, 280, 80)];    
[tmplabel setTextColor:[UIColor whiteColor]];
[tmplabel setTextAlignment:UITextAlignmentLeft];
[tmplabel setText: @"Enter your password:"];
[view addSubview:tmplabel];

Here is the recursive description:

With Xcode 4 the process for setting NSZombieEnabled is different than in earlier versions of Xcode. To configure zombies, enter ⌥-⌘-r (alt-command-r). Once the dialog is shown, choose the option Enable Zombie Objects

When using a zombie, any message sent to an object that has already released will result in an exception being thrown, which will look similar to the screenshot below:

The first thing to understand is that commands can only be entered into GDB when the debugging process is stopped, which is done via breakpoints. If you hit a breakpoint, the debug console will look as follows:

Notice the (gdb) prompt, politely waiting your input. No better place to start than requesting help information. While in the debug console (and on a breakpoint), from the GDB prompt, type in “help”

Once the high-level help categories are shown, you can look further by viewing one of the classes of commands. For example, below is a list of all the commands for examing data:

GDB Print Command

From the help info shown above, let’s look at the print command:

The expression (EXP) to be printed can be as simple as showing the current value of a variable – for example, using the code below, here’s how to print the value of the variable ‘counter’

#define MAX_CLICK  5
 
- (void)someMethod:(int)counter title:(NSString *)title message:(NSString *)msg
{
  if (counter++ > MAX_CLICK)
  {
    UIAlertView* alertView = [[UIAlertView alloc] initWithTitle:title 
      message:msg delegate:self cancelButtonTitle:@"Ok" otherButtonTitles:nil];
    [alertView show];
  }
}

Each time the method above stops on breakpoint at the if statement, the value of counter can be viewed:

Notice the shortcut for print (p) command is used above in the second command.

You can also use expressions when working with variables. Understand the examples that follow are a bit contrived, however, for the sake of illustration please bear with me. Notice that depending on how use define an expression, the value of the expression will vary:

GDB Print-Object Command

Looking at the help information for the data commands, notice there is also a print-object command, which will call the description method of an Objective-C object. Let’s assume we call someMethod (which is listed above), using the following call:

[self someMethod:x++ title:@"Error Message" message:@"Max Counter Value Reached."];

If we were to set a breakpoint at the line if (counter++ > MAX_CLICK), we could view the objects title and msg:

Notice the shortcut for print object (po) is used in the second example above.

Print-object is very helpful when looking at objects that are collections, for example NSDictionary and NSArray objects. We can view the following dictionary object using the print-object command:

NSArray *arrayOfDictionaryObjects = [NSArray arrayWithObjects:
      [NSDictionary dictionaryWithObjectsAndKeys:@"1234", @"accountID", [NSNumber numberWithBool:YES],  @"isActive", nil],
      [NSDictionary dictionaryWithObjectsAndKeys:@"2345", @"accountID", [NSNumber numberWithBool:NO],  @"isActive", nil],
      [NSDictionary dictionaryWithObjectsAndKeys:@"3456", @"accountID", [NSNumber numberWithBool:YES], @"isActive", nil],
      [NSDictionary dictionaryWithObjectsAndKeys:@"4567", @"accountID", [NSNumber numberWithBool:NO],  @"isActive", nil], nil];

At this point, even with this cursory introduction to GDB, hopefully you have a basic idea of the power of GDB. In future posts I dive further into GDB and show you how to make the most of debugging from the command interface.

- (void)buttonPressed:(UIButton *)button
{
  NSLog(@"\n Function: %s\n Pretty function: %s\n Line: %d\n File: %s\n Object: %@",
   __func__, __PRETTY_FUNCTION__, __LINE__, __FILE__, button);    
 
  ...
}

The output from the above:

In addition to the macros, there are four Objective-C expressions which provides additional information about the current context in your code. Three of the four expressions are shown in the example below:

- (void)buttonPressed:(UIButton *)button
{
  NSLog(@"Current selector: %@", NSStringFromSelector(_cmd));
  NSLog(@"Object class: %@", NSStringFromClass([self class]));
  NSLog(@"Filename: %@", [[NSString stringWithUTF8String:__FILE__] lastPathComponent]);
 
  ...
}

The fourth expression available in Objective-C creates an array, where each entry is a string representing a value in the current stack trace. Here is how to print the stack trace:

NSLog(@"Stack trace: %@", [NSThread callStackSymbols]);

With a breakpoint set, right click (or control-click) on the breakpoint indicator, the blue area shown below in the screenshot below:

The popup dialog below will be shown, select Edit Breakpoint:

At this point you will be shown the dialog below. I configured the settings to only trigger the breakpoint if the value of counter is > 2. When this occurs, a message will be spoken that indicates the breakpoint name and hit count (how many times the breakpoint has been activated).

The above is just one of many options for triggering and configuring breakpoint settings. When you get a chance, I recommend you take a few minutes to get familiar with the options for managing breakpoints. And who knows, the voice response may come in handy for those times when you are looking crossed-eyed at the screen from endless hours of coding…

Below is a partial listing of a report:

Crash Reports in Xcode and Organizer

If you are in the midst of writing an application that has crashed on a development device, you can view crash reports from within Xcode Organizer:

- Open Organizer
- Select the Devices option (on the top of the screen)
- Select the device on menu (left side of the screen)
- Choose Device Logs

Notice the list includes all the apps that have crashed on the device, not only the applications that you’ve written.

Crash Reports and the App store

For applications that a user has installed from the App Store, crash logs will be uploaded to Apple and you can download using iTunes Connect. For example, if you have an application that is available on the App Store and a user has notified you that the app crashed, you can access the crash report:

- Log into the iOS Dev Center
- From the menu in the upper right, choose iTunes Connect
- Select Manage Your Applications
- Click on the application you are interested for which you want to see the reports
- Select the View Details option below if application icon
- Select the Crash Reports link

Crash Reports with Ad Hoc and Enterprise Apps

When a device is synchronized with iTunes, crash reports are copied from the device onto the system running iTunes. To have a user get a copy of the crash report to you, they will need to locate the report(s) from the local system and make the report available to you (email, etc).

The location of the report is dependent on the OS:

Mac OS X: ~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>

Windows XP: C:\Documents and Settings\<USERNAME>\Application Data\Apple Computer\Logs\CrashReporter\MobileDevice\<DEVICE_NAME>

Windows Vista or 7: C:\Users\<USERNAME>\AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDevice\<DEVICE_NAME>

<DEVICE_NAME> is the name set for the device (go to Settings – General – About)
<USERNAME> is the name used when logging into the computer.

Crash Report Files

The files of the most help are those that end in .crash files. The crash report’s filename begins with the application name and contains date/time information. In addition, <DEVICE_NAME> will appear at the end of the file name, before the extension.

When locating crash log files, the files are written with the following format:

appName_date_deviceName.crash

For example: iPhoneApp_2011-07-25-094420_MyiPhone.crash

This feature works well if you need to log information from within your app and make the log available for offline viewing at another time. I’ve used idea this a number of times to save debugging information for later viewing.

UIFileSharingEnabled

The first step is to add the flag UIFileSharingEnabled to the application plist file. If you edit the plist as XML, you can add the flag as shown here:

<key>UIFileSharingEnabled</key>
<true/>

Using the plist editor, the entry is as shown below:

Write a file to Document Directory

With the property file updated, the next step is to write a file to the Documents directory within the app. The code below creates an array as well as a dictionary object and writes both containers to a file named DictionaryContents.text.

- (void) writeFileToDocumentDirectory
{
  NSArray *grains = [NSArray arrayWithObjects: 
                    @"Caramunich", @"Hallertauer", @"Special B", nil];
 
  NSDictionary *dictionary = [NSDictionary dictionaryWithObjectsAndKeys:
                             grains, @"arrayKey", @"Magnum", @"hopKey", @"Belgian Strong", @"yeastKey", nil];
 
  // Get path to documents directory
  NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, 
                                                       NSUserDomainMask, YES);
  if ([paths count] > 0)
  {
    // Path to save dictionary
    NSString  *dictPath = [[paths objectAtIndex:0] 
                           stringByAppendingPathComponent:@"DictionaryContents.text"];
    // Write dictionary
    [dictionary writeToFile:dictPath atomically:YES];    
  }
}

Call the method above somewhere in your application to write the file to the Documents directory.

iTunes File Sharing

To view the file within iTunes, plugin your device and select your device in the DEVICES section on the left:

Choose the Apps button on the top of iTunes and scroll to the bottom of the screen, you will see a list of all the apps that can transfer files between your computer and your device.

Save the file DictionaryContents.txt to your system, the contents will look as follows:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>arrayKey</key>
  <array>
    <string>Caramunich</string>
    <string>Hallertauer</string>
    <string>Special B</string>
  </array>
  <key>hopKey</key>
  <string>Magnum</string>
  <key>yeastKey</key>
  <string>Belgian Strong</string>
</dict>
</plist>

Copy Files To An App

You can also copy files from your system to the Documents directory, making the files accessible to your app – drag/drop files onto the Sandbox Documents area.

Keeping Data Private

- If you need to keep application information private, do not store the files in the Documents directory. Instead, store private information in the Library directory, or a folder within that directory. With one exception, the Library directory and all its sub-directories will be preserved across application backups and updates – /Library/Caches is not saved.

- With file sharing, you cannot share files between applications.

In the example below, I allocate an array, however I don’t add any elements to the array. Inside the try block the attempt to access the first element will cause an exception to be thrown.

NSArray* arraytest = [[NSArray alloc] init];
 
@try 
{
  // Attempt access to an empty array
  NSLog(@"Object: %@", [arraytest objectAtIndex:0]);
 
}
@catch (NSException *exception) 
{
  // Print exception information
  NSLog( @"NSException caught" );
  NSLog( @"Name: %@", exception.name);
  NSLog( @"Reason: %@", exception.reason );
  return;
}
@finally 
{
  // Cleanup, in both success and fail cases
  NSLog( @"In finally block");
 
  [arraytest release];
}

The output of the code is shown below:

iPhoneApp[4464:b903] NSException caught
iPhoneApp[4464:b903] Name: NSRangeException
iPhoneApp[4464:b903] Reason: *** -[NSArray objectAtIndex:]: index 0 beyond bounds for empty array
iPhoneApp[4508:b903] In finally block

The @finally clause is called regardless of the outcome of the code the in @try block. This is the perfect place to perform any relevant code cleanup.

Using exceptions can be helpful when working with files (for example NSFileHandleOperationException), when working with data from unknown sources, etc.

Catching a Specific Exception

Using NSException as shown in the @catch statement above, will result in all exceptions being caught. You can also look for a specific exception – the code below looks only for NSRangeException:

@try 
{
  // Attempt access to an empty array
  NSLog(@"Object: %@", [arraytest objectAtIndex:0]);
 
}
@catch (NSRangeException *exception) 
{
  // Print exception information
  NSLog( @"NSRangeException caught" );
  NSLog( @"Reason: %@", exception.reason );
  return;
}
@finally 
{
  // Cleanup, in both success and fail cases
  NSLog( @"In finally block");
 
  [arraytest release];
}

Throwing an Exception

You can also throw an exception in your own code. Although a bit contrived (as a means to get the point across), the method testException() shown below will throw an exception whenever it is called:

- (void)testException
{
  if (1 == 1) 
  {
    NSException *exception = [NSException exceptionWithName: @"Exception!"
                                                     reason: @"Something not so good occurred."
                                                   userInfo: nil];
    @throw exception;
  }
}

Further along in the code, when testException() is called, wrap the invocation in a try/catch/finally blocks in a manner similar to what was shown above:

@try 
{
  // Call the method...
  [self testException];
}
@catch (NSException *exception) 
{
  // Print exception information
  NSLog( @"NSException caught" );
  NSLog( @"Name: %@", exception.name);
  NSLog( @"Reason: %@", exception.reason );
  return;
}
@finally 
{
  NSLog( @"In finally block");
}

iPhoneApp[4660:b903] NSException caught
iPhoneApp[4660:b903] Name: Exception!
iPhoneApp[4660:b903] Reason: Something not so good occurred.
iPhoneApp[4660:b903] In finally block

As an example, I’ve used assertions during early development phases when working with web services – as I was writing the iPhone app another team was developing web-services and programming interfaces to the same. As we were getting parameter passing to work, assertions were very helpful to check expected values.

Using Assertions in Objective-C Methods

Two categories of assertions are available when writing iOS apps, assertions for use within Objective-C methods, and assertions that are used inside a C-based function. Let’s start with method based assertions:

NSAssert and its kin – NSAssert1, NSAssert2, etc – are used inside methods. NSAssert is defined as follows:

#define NSAssert(condition, desc)

condition is the expression we are interested to evaluate and desc is the message displayed on the console when the assertion fails.

Looking a little further, in NSException.h we can see the full definition:

#define NSAssert(condition, desc, ...) \
    do {			\
	if (!(condition)) {	\
	    [[NSAssertionHandler currentHandler] handleFailureInMethod:_cmd \
		object:self file:[NSString stringWithUTF8String:__FILE__] \
	    	lineNumber:__LINE__ description:(desc), ##__VA_ARGS__]; \
	}			\
    } while(0)

Notice the check for !(condition) – if the condition check fails, an exception is generated with information about the file where the error occurred and the line number within that file.

The following example shows how you might go about using an assertion:

- (void) sanityCheck:(int)x
{
  // Other code here...
 
  NSAssert((x > 0) && (x < 100), @"x is not within the acceptable range of 1-99");
}

If the value of x is not between 1 and 99, an exception will be generated and the following output will be shown in the console:

In addition to the basic NSAssert macro, there are macros available that enable additional information to be output into the description field. For example, the macro below takes an additional parameter, arg1, that can be used to show the value of a variable in the output:

#define NSAssert1(condition, desc, arg1)

NSAssert1((x > 0) && (x < 100), @"x is: %i, acceptable range is: 1-99", x);

The output is shown below:

Taking this one step further, the example below shows NSAssert3, which will accept three arguments:

#define MIN_VALUE 1 
#define MAX_VALUE 99
 
NSAssert3((x > 0) && (x < 100), @"x is:%i, acceptable range is:%d-%d", x, MIN_VALUE, MAX_VALUE);

The output is essentially the same as in the previous example, however, the values for the range as derived from the min and max value definitions.

The entire range of macros for Objective-C methods is: NSAssert, NSAssert1, NSAssert2, NSAssert3, NSAssert4 and NSAssert5.

Using Assertions in C Functions

Assertions can also be used within C functions and work in a very similar fashion as with Objective-C methods. There is a range of macros with the naming conventions NSCAssert, NSCAssert1, NSCAssert2, etc. NSCAssert looks as follows:

NSCAssert(condition, NSString *description)

You use these macros in C functions in the same manner as shown above.

Disabling Assertions

I typically use assertions during development only – you can disable assertions by adding the preprocessor macro NS_BLOCK_ASSERTIONS in the build settings for your Release builds.

The screenshot below shows how to configure the Build Settings inside Xcode 4 to add NS_BLOCK_ASSERTIONS.

NSZombieEnabled is an environment variable which can be helpful to track down the elusive object causing the problem. With the environment variable set, Cocoa will redirect all objects isa pointer to an NZZombie object once an objects retain count has reached zero. In the future, should you try and send a message to a previously released object, an exception will be raised showing a message similar to the following:

Setting NSZombieEnabled Environment Variable

In the Groups and Files section, expand the Executables section and right click on your app name and choose Get Info from the dialog:

Select the Arguments tab on the top and then add a new entry in the Variables to be set in the environment section. Name the new variable to NSZombieEnabled and set its value to YES.

Tracking Down the Error

Using a zombie, messages sent to an object that has already released will now generate the exception shown above, and following the stack track should now help you find the location of the object that is generating the EXC_BAD_ACCESS error.

Don’t forget to remove the environment variable, or at a minimum untick the checkbox once you find the source of the problem.