coding 的演示功能不让用，原来搭建的博客访问不了了。索性将全部博客迁移到简书，这篇是旧文章，欢迎大家以后来简书看我的博客
昨天发现微博的圈子里iOS学习氛围比较好，所以特意注册了一个新浪微博。无意中在微博里看到了@没故事的卓同学的文章Xcode7中你一定要知道的炸裂调试神技，介绍Xcode7中新增了AddressSanitizer工具可以捕获EXC_BAD_ACCESS。然而Xcode中不是已经有了Zombie了么？怎么又出来了一个Address Sanitizer，他们有什么区别呢？
AddressSanitizer VS Zombie
原理
-
zombie：
zombie的原理是用生成僵尸对象来替换dealloc的实现，当对象引用计数为0的时候，将需要dealloc的对象转化为僵尸对象。如果之后再给这个僵尸对象发消息，则抛出异常，并打印出相应的信息，调试者可以很轻松的找到异常发生位置。 -
AddressSanitizer：
AddressSanitizer的原理是当程序创建变量分配一段内存时，将此内存后面的一段内存也冻结住，标识为中毒内存。如图所示，黄色是变量所占内存，紫色是冻结的中毒内存。
当程序访问到中毒内存时（越界访问），就会抛出异常，并打印出相应log信息。调试者可以根据中断位置和的log信息，识别bug。如果变量释放了，变量所占的内存也会标识为中毒内存，这时候访问这段内存同样会抛出异常（访问已经释放的对象）。
适用性
了解原理之后我们可以大概猜到Zombie和AddressSanitizer的适用性，不过一切还得以实验结果为准：
实验后发现AddressSanitizer比Zombie拥有更强大的捕获能力，特别是在malloc对象和内存越界方面，zombie几乎无能为力。如果在debug的时候无法捕获异常，上线之后crash log中概率性的EXC_BAD_ACCESS简直是一种灾难。
缺陷
上面研究发现AddressSanitizer比zombie更有优势，那么AddressSanitizer有什么缺陷呢？
- AddressSanitizer可能会没有log，不过会在访问中毒内存的代码处断住，这倒是对debug影响不大
- 使用AddressSanitizer除了分配对象的内存之外，还需要额外的内存，这会导致App内存大量增加，用起来有可能会比较卡
虽然AddressSanitizer有一些缺陷，但是总的来说AddressSanitizer还是一个非常好用的debug工具。
AddressSanitizer使用
在了解AddressSanitizer的功能之后，我们来看看AddressSanitizer用。
AddressSanitizer的使用其实非常简单，在Xcode上方选择设备的地方，点击工程名字，选择Edit Scheme.
在Diagnostics中选中enable address sanitizer即可。
AddressSanitizer开启之后，在debug过程中，如果遇到EXC_BAD_ACCESS的问题，Xcode会自动中断，抛出异常
其他compiler flags
实际AddressSanitizer很早以前就有了，只是没在Xcode中集成而已。除了AddressSanitizer还有很多其他的compiler flags，undefined-trap就是其中的一种。undefined-trap的功能也非常强大，它可以检测出程序中的不明确行为，如数据溢出等。
下面我们以undefined-trap举例，看看怎么用其他的compiler flags：
在Build Settings中的Custom Compiler Flags下为other C Flags添加-fsanitize=undefined-trap -fsanitize-undefined-trap-on-error
完成undefined-trap的设置之后，当程序的数据发生溢出行为时，系统就会抛出异常。
End
经过ARC的洗礼之后，普通的访问释放对象产生的EXC_BAD_ACCESS已经大量减少了，现在出现的EXC_BAD_ACCESS有很大一部分来自malloc的对象或者越界访问。简单的敌人已经被干掉，剩下的都是难缠的对手了。还好Apple给我们升级了装备，以后遇到EXC_BAD_ACCESS应该不用那么心惊胆战了吧？
Reference
Xcode7中你一定要知道的炸裂调试神技
在Xcode 7上直接使用Address Sanitizer
Clang 3.8 documentation
