Over the Edge of Time: Accessing Nil!

    

OR

Why you never want to complain about waiting in the airport 

while they do a

little maintenance

The Well-Behaved Version

There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "x86_64-apple-darwin".tty /dev/ttys000

Loading program into debugger…

Program loaded.

run

[Switching to process 31280]

Portal Pilots Maintenance Flight. Scanning for UNIQUE Time Portals

portals[0] = bridge

portals[1] = creek

portals[2] = path

portals[3] = alley

Running…

Debugger stopped.

Program exited with status value:0.

But Wait!

HERE’S WHAT HAPPENS WHEN THE ARCH-ENEMY OF PORTAL PILOTS MANAGES TO GET HIRED ONTO THE DEVELOPMENT STAFF

(just tought I'd try to access nil and see where it took me!)

// If I ever want to totally gum up the works, I'll make sure to try to access past the end of the array!

Portal Pilots Maintenance Flight. Scanning for UNIQUE Time Portals

portals[0] = bridge

portals[1] = creek

portals[2] = path

portals[3] = alley

2010-11-16 12:14:54.431 encounterPortals[31239:a0f] *** __NSAutoreleaseNoPool(): Object 0x10010cce0 of class NSCFString autoreleased with no pool in place - just leaking

2010-11-16 12:14:54.433 encounterPortals[31239:a0f] *** __NSAutoreleaseNoPool(): Object 0x1001107d0 of class NSCFString autoreleased with no pool in place - just leaking

2010-11-16 12:14:54.433 encounterPortals[31239:a0f] *** __NSAutoreleaseNoPool(): Object 0x1001023b0 of class NSException autoreleased with no pool in place - just leaking

2010-11-16 12:14:54.434 encounterPortals[31239:a0f] *** __NSAutoreleaseNoPool(): Object 0x1001108e0 of class _NSCallStackArray autoreleased with no pool in place - just leaking

2010-11-16 12:14:54.434 encounterPortals[31239:a0f] *** __NSAutoreleaseNoPool(): Object 0x100110a90 of class _NSCallStackArray autoreleased with no pool in place - just leaking

2010-11-16 12:14:54.448 encounterPortals[31239:a0f] *** __NSAutoreleaseNoPool(): Object 0x100110e30 of class NSCFString autoreleased with no pool in place - just leaking

2010-11-16 12:14:54.495 encounterPortals[31239:a0f] *** __NSAutoreleaseNoPool(): Object 0x100111440 of class NSCFString autoreleased with no pool in place - just leaking

2010-11-16 12:14:54.496 encounterPortals[31239:a0f] *** __NSAutoreleaseNoPool(): Object 0x100111890 of class NSConcreteMutableData autoreleased with no pool in place - just leaking

2010-11-16 12:14:54.497 encounterPortals[31239:a0f] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSCFArray objectAtIndex:]: index (4) beyond bounds (4)'

*** Call stack at first throw:

(

       0   CoreFoundation                      0x00007fff884d8cc4 __exceptionPreprocess + 180

       1   libobjc.A.dylib                     0x00007fff86f250f3 objc_exception_throw + 45

       2   CoreFoundation                      0x00007fff884d8ae7 +[NSException raise:format:arguments:] + 103

       3   CoreFoundation                      0x00007fff884d8a74 +[NSException raise:format:] + 148

       4   Foundation                          0x00007fff801db084 _NSArrayRaiseBoundException + 122

       5   Foundation                          0x00007fff8013db59 -[NSCFArray objectAtIndex:] + 75

       6   encounterPortals                    0x0000000100000dfd main + 417

       7   encounterPortals                    0x0000000100000c54 start + 52

       8   ???                                 0x0000000000000001 0x0 + 1

)

terminate called after throwing an instance of 'NSException'

Program received signal:  “SIGABRT”.

sharedlibrary apply-load-rules all

kill

quit

// encounterPortals

// PortalPilots encounter a variety of Time Portal Types

// based on accesselements page 166, Holzner

#import <Foundation/Foundation.h>

// IMPORTANT STUFF

//  1) End arrays with the nil object

//  2) Use @ to differentiat OBJECTIVE C strings from C-style strings

int main (int argc, const char * argv[]) {

    NSArray *portals = [[NSArray alloc] initWithObjects:@"bridge", @"creek",@"path", @"alley", nil];

    printf("Portal Pilots Maintenance Flight. Scanning for UNIQUE Time Portals \n");

    printf("portals[0] = %s \n", [[portals objectAtIndex: 0] cString]);

     printf("portals[1] = %s \n", [[portals objectAtIndex: 1] cString]);

    printf("portals[2] = %s \n", [[portals objectAtIndex: 2] cString]);

     printf("portals[3] = %s \n", [[portals objectAtIndex: 3] cString]);

   

    // Thought it would be interesting to try to access nil

    // Wow! Leaking - What IS leaking? And all kinds of neat errors

  

    //printf("portals[4] = %s \n", [[portals objectAtIndex: 4] cString]);

    return 0;

}

Debugging: Hey bobcat, to catch a fish, you gotta think like a fish

 

There was a kid’s book I had, when I still was a kid, about a native American child. Her elders told her that to catch a fish, she had to think like a fish. Or maybe it was bear, or a mountain goat. I don’t actually remember. So Little Bobcat developed her analytical little wits and finally caught herself a fish.

There’s a lot I have yet to learn about the XCODE debugger. In fact, just about everything.  I haven’t even figured out where to go to learn about how the debugger works. I’m still just looking at error messages and going from there. Tonight I had ‘duplicate symbol _main’. I clicked on every highlighted place I could find. I looked at the thread displaying the hierarchy of file names. I looked through each of the five files I’d created, but I only found the word ‘main’ in one place. * Finally I just decided to think like a fish.

Somewhere, I must have more than one of those lines that looks like this

int main(void) {

but I sure didn’t see it in any of my ‘.m’ or ‘.h’ files.

So I started opening up gates. That’s what a fish would do, right? A fish like XCODE looks at all the files in the project. (One heck of a smart fish) and that fish recognizes the name of the project. So the fact that I was expecting my fish to only respond to the lines  (my fishing line that is) in a file called ‘main.m’, didn’t mean that she wasn’t going to look around for other files. Particularly a file with the same name as my project – ‘protocols.m’, a file created by default in a folder called ‘SOURCE’ when I created a new project. Sure enough, there was the culprit line. More than one ‘main’ makes trouble.

Cast your (main) lines upon the water, but only one at a time.

* After I resolved this error,  it occurred to me that ‘find in project’ would have been another good way to scout out this problem.