经常有朋友会问Crash的问题。Crash最多的无非就两种,一种就是signal SIGABRT,大概的意思就是发送Message出现问题,信号迷失了。这种的Crash其实是很好定位,Crash了后直接看Console里出的最后日志,比如这段:
2012-03-28 19:26:33.055 TableViewMenuDemo[3916:f803] *** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘-[__NSArrayI replaceObjectAtIndex:withObject:]: unrecognized selector sent to instance 0x6a3f3d0′
*** First throw call stack:
找到reason字段,那就是原因,说NSArray 调用
replaceObjectAtIndex:withObject:
这个方法是NSMutableArry的,NSArray并没有该方法。信号迷失掉了,所以Crash了。
0x6a3f3d0 是出问题的内存地址,查下内存地址或搜下调用方法就比较好定位了。
![](http://www.cocoachina.com/cms/uploads/allimg/121120/4673_121120140536_1.png)
Xcode4上还有个更好用的定位方法,就是设置一个Exception Breakpoint就好了。
看图在工程的左边栏中选择Breakpoint Navigator,点击下面的+号添加一个Exception Breakpoint,然后再运行试试,Crash后,是不是直接定位到了那行代码了?再根据Console里的日志进行定位修改就好了。
下面说说另一种Crash, EXC_BAD_ACCESS,这个比较头疼,因为Crash的时候,可能是比较早之前的某个变量释放了,现在访问时出问题。Console里也没显示什么日志。
这里光加入Exception Breakpoint是不够的了,XCode4还个可爱的地方,打开Scheme选项选择EditScheme。
![](http://www.cocoachina.com/cms/uploads/allimg/121120/4673_121120140643_1.png)
![](http://www.cocoachina.com/cms/uploads/allimg/121120/4673_121120140711_1.png)
然后按图勾上Enable Zombie Objects和Malloc Stack那两项,记住一般只有在定位EXC_BAD_ACCESS时候才勾选,别有事没事都勾上。
这样重新跑一下,如果是到Exception Breakpoint处停止了,可以在Console中输入:c(continue)按回车继续跑,直到Crash。看下Console是不是有跟SIGABRT类似的错误信息日志了,后面定位什么的你懂的。
如果还没有日志,在Console中输入po$eax$eax标志出错的地方,适用模拟器,真机用$r0(话说EXC_BAD_ACCESS这种错误模拟器定位就行),还可以输入比如:po[$eaxname]po[$eaxreason]等指令查看错误其他信息(注意方括号后没分号的)。然后,就没有然后了。
还要补充点,程序开发过程就要多关注左边栏中Issue Navigator里的警告信息,Xcode4不仅会警告,还多数给出解决建议,能避免后面不必要的Crash。
![](http://www.cocoachina.com/cms/uploads/allimg/121120/4673_121120140842_1.png)
如果程序Crash,第一时间关注下debug Navigator里的执行信息,将滑块拉向右边可以看到更多调用信息,根据这个能大致设想是调用什么方法或进行什么操作时Crash的。
![](http://www.cocoachina.com/cms/uploads/allimg/121120/4673_121120141637_1.png)
http://www.cocoachina.com/macdev/tips/2012/1120/5136.html