xcode 调试
崩溃：
有两种最基本的crash类型常发生：SIGABRT（也叫EXC_CRASH）和EXC_BAD_ACCESS（也可能会是SIGBUS或者SIGSEGV）。
就crash而言，SIGABRT是一个比较好解决的，因为他是一个可掌控的crash。App会在一个目的地终止，因为系统意识到app做了一些他不能支持的事情。
EXC_BAD_ACCESS是一个比较难处理的crash了，当一个app进入一种毁坏的状态，通常是由于内存管理问题而引起的时，就会出现出现这样的crash。
- [UINavigationController setList:]: unrecognized selector sent to instance 0x6a33840
“unrecognized selector sent to instance XXX” 这条错误消息意味着你的app正在试着执行一个不存在的方法。这种情况的发生，主要是都是一个方法被错误的对象调用了（也就是这个对象没有这个方法，但是你调用了他，就错了）。例如在这里这个问题上，对象就是UINavigationController （在内存地址0x6a33840上），一旦得到“unrecognized selector sent to instance XXX”错误，就需要检查这个对象是不是正确类型，并且检查它真的是有那个名字的方法么。经常发现调用一个自己认为是这个对象的方法，因为指针变量可能没有包含这个正确值，所以导致很多的错误。拖拽Debug Navigator底部的滑块到最右边。它将会展示出崩溃时全部的堆栈信息：
在底部的函数start()，第一个被调用。在他的执行里面的有些地方，，main()函数在他之前。（Somewhere in its execution it called the function above it, main().）。他是应用程序的开始入口点，并且它经常在底部附近。Main()也叫UIApplicationMain()（ios）。UIApplication()在UIApplication对象里调用_run方法，_run方法里面又调用CFRunLoopRunInMode()方法，CFRunLoopRunInMode()方法里面又调用CFRunLoopSpecific()方法，就这样一直向下调用，一直到__pthread_kill。所有在这个堆栈里面的函数和方法都是灰色的，除了main()函数。那是因为他们都来自内置的ios frameworks(ios内置框架)。所以没有针对他们可见的源码。在这个堆栈里面唯一的东西就是main.m的源码，因此xcode的代码编辑器就显示了它，即使他不是这个崩溃的真正原因。
准确的找到异常在那里抛出：Add Exception Breakpoint，再次运行，代码就停在出问题的那一行上。
2.内存错误：EXC_BAD_ACCESS错误。那意味着这个app有内存管理的问题。
运行按继续，出现问题处。“this class is not key value coding-compliant for the key XXX”的错误经常都是由于你装载这个nib，但是里面引用的一些熟悉可能不存在。特别是当你在代码中移除了outlet属性后，但是你却没有在nib中移除这个连接。
