调试message send to deallocated instance问题

message sent to deallocated instance

在XCode的以前版本中,如果遇到了

[代码]c#/cpp/oc代码:

1 message sent to deallocated instance 0x6d564f0

我们可以使用info malloc-history 0x6d564f0来查看调用堆栈来查看崩溃发生的地方,这种方法这里不作阐述,大家自行百度。

在新的XCode里,调试器默认使用LLDB,我就讲一下如何在LLDB状态下定位到由于内存操作不当引起的Crash

首先我有一段会发生崩溃的代码:

[代码]c#/cpp/oc代码:

1 NSString *themePath = [[[NSBundle mainBundle] resourcePath] stringByAppendingPathComponent:themePathTmp];
2 if(themePath)
3   self.backgroundIV.image = [UIImage imageWithContentsOfFile:[themePath stringByAppendingPathComponent:@"mask_1.png"]];
4    
5 [themePath release];

学过内存管理的人都应该知道在这里themePath并没有被retain,所以如果写了release,那么必然会发生崩溃情况。首先我们需要对开发的环境变量进行设置

运行代码,出现下面的崩溃现象

下面我们打开“活动监视器”,找到我们对应的PID,我们的Target为HPThemeManager,只要找到HPThemeManager对应的PID就可以(HPThemeManager是在论坛里下载的,本来正在看代码,就直接拿他来作试验了)

现在,我们得到了两个主要的信息:

进程ID:50127

崩溃地址:0x6d564f0

我们打开终端,输入以下命令:

[代码]c#/cpp/oc代码:

1 sudo malloc_history 50127 0x6d564f0

结果显示为:

这样我们用能定位到这行代码

[代码]c#/cpp/oc代码:

1 NSString *themePath = [[[NSBundle mainBundle] resourcePath] stringByAppendingPathComponent:themePathTmp];

对themePath进行排查,就找到了崩溃的罪魁祸首

[代码]c#/cpp/oc代码:

1 [themePath release];

原文地址:http://www.devdiv.com/lldb_message_sent_to_deallocated_instance_-blog-50901-50856.html

时间: 2024-08-04 07:17:44

调试message send to deallocated instance问题的相关文章

message sent to deallocated instance EXC_BAD_ACCESS 获取更多调试信息

设置环境变量: 只在DEBUG版本设置,自己调试使用,设置这两个参数则内存是不会释放掉的. 当出现message sent to deallocated instance EXC_BAD_ACCESS,会在xcode console打印出类似的日志: 2015-09-09 12:00:54.073 TrialTest[71354:3044411] *** -[ZNNullDelegateViewController retain]: message sent to deallocated ins

Xcode调试之exc_bad_access以及 message sent to deallocated instance

如果出现exc_bad_access错误,基本上是由于内存泄漏,错误释放,对一个已经释放的对象进行release操作.但是xcode有时候不会告诉你错误在什么地方(Visual Studio这点做得很好).不过我们可以通过设置xcode环境变量环境变量NSZombieEnabled,MallocStackLogging查看错误的来源: 1.菜单 Product > Manage Schemes; 2.选中当前的Scheme,点Edit按钮: 3.设置环境变量.在Arguments > Envi

解决LLDB模式下出现message sent to deallocated instance错误

本文在源文的基础上做整理:http://www.devdiv.com/home.php?mod=space&uid=50901&do=blog&id=50856 Xcode版本7.1 IOS版本9.1 公司之前开发的一个APP,在使用环境中IOS版本升级到9.0以后,某个操作会导致程序闪退. Xcode代码中提示错误: 1 Thread 1: Program received signal:"EXC_BAD_ACCESS" 这样的提示意味着对已经释放的对象发送消

如何在LLDB下排查message sent to deallocated instance问题

转:http://www.devdiv.com/home.php?mod=space&uid=50901&do=blog&id=50856 在XCode的以前版本中,如果遇到了 [代码]c#/cpp/oc代码: 1 message sent to deallocated instance 0x6d564f0 我们可以使用info malloc-history 0x6d564f0来查看调用堆栈来查看崩溃发生的地方,这种方法这里不作阐述,大家自行百度. 在新的XCode里,调试器默认使

关于iOS8上使用UITextView内存泄漏的一个坑:-[UITextView textInputView]: message sent to deallocated instance

问题: 第一次从一个页面跳转到编辑控制器没有什么问题,当返回后再次进入编辑控制器点击UITextView出现内存泄漏错误,通过僵尸断点发现错误:-[UITextView textInputView]: message sent to deallocated instance 0x159fc800,测试环境是真机(iPhone5,iOS8.4),我又试着在iOS10的系统上测试,发现并没有什么问题,可能iOS8和10的一些内存处理策略不一样. 解决方法: 这个bug调试了很久,最后几经查阅资料,在

message sent to deallocated instance

在XCode的以前版本中,如果遇到了 1 message sent to deallocated instance 0x6d564f0 我们可以使用info malloc-history 0x6d564f0来查看调用堆栈来查看崩溃发生的地方,这种方法这里不作阐述,大家自行百度. 在新的XCode里,调试器默认使用LLDB,我就讲一下如何在LLDB状态下定位到由于内存操作不当引起的Crash 首先我有一段会发生崩溃的代码: 1 NSString *themePath = [[[NSBundle m

message sent to deallocated instance 崩溃 解决方案

一.情况 1,Xcode中有时候奔溃会提示类似这样的提示 : *** -[CAShapeLayer retain]: message sent to deallocated instance 0x27368d10 2,有时候我们会毫无头绪排查,这时候如果我们想要获取更多详细的信息那么可以用终端里的malloc_history命令来解决. 二.步骤 1,使用模拟器运行项目,并且记住项目名比如:zhihuiyun 2,记录崩溃的内存地址比如:0x27659700 3,打开活动监视器,找出你项目的pi

message sent to deallocated instance 多次释放

1.scroll view did scroll 问题:*** -[DetailPageViewController scrollViewDidScroll:]: message sent to deallocated instance 0x19a13c90原因:viewController释放之后,scrollViewDidScroll:方法又被调用,解决:将调用该方法的delegate置为nil. 2.nsindexpath section 问题: *** -[NSIndexPath sec

runtime MethodSwizzle 实践之 奇怪crash : [UIKeyboardLayoutStar release]: message sent to deallocated instance

情景: 使用MethodSwizzle 实现对数组.字典 等系统方法的安全校验.显然能达到预期效果,但实际发现当 键盘显示的情况下  home app 进入后台,再单击app  图标 切换回前台时 发生crash : [UIKeyboardLayoutStar release]: message sent to deallocated instance UIKeyboardLayoutStar 是键盘上的布局的视图吧, 整个工程都在ARC下 构建,很奇怪,而且必须. 信息: http://hua