http://www.zhaojianfei.com/archives/539 当出现message sent to deallocated instance的时候，一般伴随牛的BAD_ACCESS.是的，是某个对象release了两次。可是那么多的疑对象，到底是哪一个? 使用xcode环境变量(添加 方法 请自行google)MallocStackLoggingNo
http://www.zhaojianfei.com/archives/539
当出现message sent to deallocated instance的时候，一般伴随牛逼的BAD_ACCESS.是的，是某个对象release了两次。可是那么多的疑似对象，到底是哪一个?
使用xcode环境变量(添加方法请自行google)MallocStackLoggingNoCompact,NSZombieEnabled,MallocStackLogging这三个，值都设置成YES.寻求更详细的错误信息。
message sent to deallocated instance后会有一个内存地址，如:0×6497860,我们需要查看该地址的malloc history.查看方法，在原来的gdb下，使用”info malloc_history 0×6497860“即可显示malloc记录。但是新版的Xcode 不再支持，怎么办呢?秀逗麻袋，我们还有terminal,使用终端的malloc_history命令，如”malloc_history 32009 0×6497860“即可显示。其中的32009是该进程的pid,根据这个malloc记录，可以大致定位出错信息的代码位置。
（插一句，gdb或者lldb进行debug的向导:http://lldb.llvm.org/lldb-gdb.html）
其实，如果代码编写足够高效和有序的话，是不会出现这种烦人的问题的。还是代码重构问题。代码洁癖伤不起啊。
