message sent to deallocated instance问题的解决方法(gdb和lldb)

最新推荐文章于 2021-03-06 11:50:40 发布

转载最新推荐文章于 2021-03-06 11:50:40 发布 · 629 阅读

iOS 专栏收录该内容

21 篇文章

订阅专栏

本文介绍了如何在Xcode环境下使用MallocStackLoggingNoCompact、NSZombieEnabled、MallocStackLogging三个环境变量设置为YES来获取更详细的错误信息，以及在gdb或lldb下通过infomalloc_history或terminal的malloc_history命令查找导致messagesenttodeallocatedinstance问题的内存地址，从而定位出错信息的代码位置。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

message sent to deallocated instance问题的解决方法(gdb和lldb)

当出现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）

其实，如果代码编写足够高效和有序的话，是不会出现这种烦人的问题的。还是代码重构问题。代码洁癖伤不起啊。