Question

Every time Xcode crashes it points to this line on main.m

int retVal = UIApplicationMain(argc, argv, nil, @"AppController");

I know Xcode 4 debugging stinks compared to 3.x, but how do I make it point to the line where the crash happened.

Please don’t:

1. Tell me to enable NSZombieEnabled;
2. Tell me to add an exception breakpoint to break for all exceptions on Catch or on Throw.
3. Tell me Xcode 4.x is better than 3.x for debugging.

All this stuff is useless or barely useless and Xcode continues to crash on the same line on main.m…

Please save me from this.

Thanks.

Answer 1

Here’s an idea: just one try/catch around your entire app, logging the stack from the exception, not the current stack (i.e. not a breakpoint + inspection):

main.m

int main(int argc, char *argv[])
{
    @autoreleasepool {
        @try {
            return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
        }
        @catch (NSException *exception) {
            NSLog(@"%@",[exception callStackSymbols]);
            return 1;
        }
    }
}

My understanding is that the reason we don’t have a good method otherwise is that the crash itself does not happen until later in the runloop. I think things like uncaught exceptions, etc. just put the app in a state where it will crash somewhere in Apple’s code when the runloop iterates. This is similar to if you ever have crashes in the UI… it doesn’t always crash when you set the crappy geometry, it crashes when it tries to use it. For this reason, we need to get the stack from the exception object, not from the current-state when the crash actually occurs.

And I’ll add this just because it got me a few times when I thought I had no info available, but I just didn’t know Xcode well enough yet (I’m sure it’s common knowledge and I was just being silly). Sometimes when I think that all I have is that dreaded top-level scope, all I needed to do was use the little slider at bottom-left (during debug sessions) to see the whole stack. This is often nearly useless, for the reasons mentioned above (it’s in another part of the runloop from the problem).