iphonecrash

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


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?


Solution

  • 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!");