Xcode调试技巧—在系统抛出异常处设置断点

有时候我们的程序不知道跑到哪个地方就 crash 了，而 crash 又很难重现。
保守的做法是在系统抛出异常之前设置断点，具体来说是在 objc_exception_throw处设置断点。
设置步骤为：首先在 XCode 按 CMD + 6，进入断点管理窗口；
然后点击右下方的 +，增加新的 Symbolic Breakpoint。
在 Symbol 一栏输入：objc_exception_throw，然后点击 done，完成。
这样在 Debug 模式下，如果程序即将抛出异常，就能在抛出异常处中断了。
比如在前面的代码中，我让 [firstObjctcrashTest]; 抛出异常。在 objc_exception_throw 处设置断点之后，程序就能在该代码处中断了，我们从而知道代码在什么地方出问题了。

经常有朋友会问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 是出问题的内存地址,查下内存地址或搜下调用方法就比较好定位了。
 



 
Xcode4上还有个更好用的定位方法，就是设置一个Exception Breakpoint就好了。
 
看图在工程的左边栏中选择Breakpoint Navigator,点击下面的+号添加一个Exception Breakpoint，然后再运行试试，Crash后，是不是直接定位到了那行代码了？再根据Console里的日志进行定位修改就好了。
 
下面说说另一种Crash, EXC_BAD_ACCESS,这个比较头疼，因为Crash的时候，可能是比较早之前的某个变量释放了，现在访问时出问题。Console里也没显示什么日志。
 
这里光加入Exception Breakpoint是不够的了，XCode4还个可爱的地方，打开Scheme选项选择EditScheme。
 



 



 
然后按图勾上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。
 



 

如果程序Crash，第一时间关注下debug Navigator里的执行信息，将滑块拉向右边可以看到更多调用信息，根据这个能大致设想是调用什么方法或进行什么操作时Crash的。
 



 

 

 
 
 
 
 
来源：DEVDIV博客-History
 

转自：http://www.cocoachina.com/applenews/devnews/2012/1123/5166.html