iOS 开发之EXC_BAD_ACCESS异常分析

一：EXC_BAD_ACCESS异常介绍
在调试objective-c程序的过程中，程序crash的现象在所难免，但大部分的错误都能够通过显示的错误原因结合NSLog的方式来解决，比如 NSInvalidArgumentException（名字就能看出来是什么错误）等，实在搞不定还有debug这个杀手锏。但唯独 EXC_BAD_ACCESS这个异常太难处理了，名字看不出来是什么原因，其他提示也没有，debug都搞不定。
先来介绍下EXC_BAD_ACCES：这个异常基本上是内存使用不当造成的，而且90%的错误来源在于对一个已经释放的对象进行release操作。

二：分析方法
为工程运行时加入 NSZombieEnabled 环境变量，并设为启用，则在 EXC_BAD_ACCESS 发生时，XCode 的 Console 会打印出问题描述。并同时添加MallocStackLogging和MallocStackLoggingNoCompact两个环境变量，来启用 malloc记录

三：输出信息
只要添加了NSZombieEnabled变量，在发生EXC_BAD_ACCESS会在concole中打印出错误原因，绝大多数都会出现这个信息

ok，很显然，问题是来源就是对一个已经释放的对象进行release操作（这里就是HotCategoryViewController了）这样基本上 可以定位出来是在哪里出现了错误，错误的对象是什么，但在很多情况下，这还不够。接下来还有一招，在concole里面通过gdb的调试命令来看下当前实 例从alloc到free的整个生命周期的调用过程在concole里面敲：shell malloc_history App_PID Object_instance对应我们的例子为：2011-10-27 15:12:40.061 iAliexpress[177:707] *** -[HotCategoryViewController setTitle:]: message sent to deallocated instance 0x3a89c0这里就应该输入：shell malloc_history 177 0x3a89c0其中App_PID为当前的进程号（若你是用模拟器调试，没问题;若你是用真机调试，抱歉，你看到的进程号是手机里的，你这里拿来没 用），Object_instance为该实例对象的id。回车后你会得到这样的信息