IPhone program crash and stack report shown by compiler is totally useless!

Question

Most of the times when Iphone program crash, compiler show stack with full of no's, but these no's don't make any sense to me. Very rarely it point out where the problem might be and mostly there are these useless no's. How you can make sure that when your program crashes while development/testing, it shows at what place this cause this crash?

Answer 1

Things to do:

1) Debug with breakpoint on

2) Add a global breakpoint: objc_exception_throw

Then look in the Debugger window

Answer 2

My iPhone dev life was horrible until I found NSZombieEnabled. By adding this flag into your executable, it will help you see any memory issues by letting you know what the name of the object that is at fault is.

This works by never actually releasing an object, but by wrapping it up as a "zombie" and setting a flag inside it that says it normally would have been released. This way, if you try to access it again, it still know what it was before you made the error, and with this little bit of information, you can usually backtrack to see what the issue was.

It especially helps in background threads when the Debugger sometimes craps out on any useful information.

VERY IMPORTANT TO NOTE however, is that you need to 100% make sure this is only in your debug code and not your distribution code. Because nothing is ever release, your app will leak and leak and leak. To remind me to do this, I put this log in my appdelegate:

if(getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled"))
  NSLog(@"NSZombieEnabled/NSAutoreleaseFreedObjectCheckEnabled enabled!");

Answer 3

The key word you are looking for is "symbolicate". If you have a crash log from a device, you have to sun symbolicate on it in order to have the stack trace give you line numbers.

The function I have in my .profile to help me run the command is:

function desym
{
/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash -A -v $1 | more
}

Basically you put the app bundle, the dsym file generated at build, and the crash log in the same directory and then run "dysm [CrashLog File Name]" to have the symbols correctly shown in the stack trace.

Note that it must be the same executable and dysm file that generated the crash! Every time you recompile, locations of things can change.