EXC_BAD_ACCESS

这是一个 “EXC_BAD_ACCESS”错误。我们打开XCode的选项:“NSZombieEnabled” 。在crash时可能会给你更多的一些提示信息。

设置步骤:1


2:勾上红色框里的


运行,按刚才的操作选中其中的cell。再次crash,这次在output窗口会看到多了一项错误信息:

2012-11-28 13:22:08.911 PropMemFun[2132:11303] *** -[CFString respondsToSelector:]: message sent to deallocated instance 0x713ebc0

大概意思是:向已释放的内存发送消息。也就是说使用了已释放的内存,在C语言相当于使用了“野指针”


看了下crash的这个语句,sushiString应该是没问题的,它是从stringWithFormat初始化出来的。那就是_lastSushiSelected的问题。

_lastSushiSelected指向了sushiString,sushiString是一个autorelease变量。 在第二次点击时,使用的是sushiString已经被释放,所以crash了。那为_lastSushiSelected保留一下,就可以用了。代码修改如下:

[cpp]  view plain  copy
  1. <span style="font-size:14px;">    _lastSushiSelected = [sushiString retain];  
  2. </span>  

运行,这时候不崩溃。


  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
iOS中的exc_bad_access通常是由于访问了无效的内存地址而触发的错误。要解决这个问题,我们可以遵循以下几个步骤: 1. 检查Crash日志:首先,我们应该查看Crash日志以了解问题的具体原因。Crash日志将显示出错的位置以及相关的堆栈信息,这有助于我们确定问题的根源。 2. 使用断点:如果我们知道大概出错的位置,可以在代码中设置断点来逐步调试。这样,我们可以在错误出现前暂停应用程序的执行,从而更好地分析错误。 3. 检查空指针:空指针访问是常见的exc_bad_access错误。我们应该检查代码中的指针变量是否为空并确保在使用前进行了正确的初始化。 4. 检查内存释放:内存管理是另一个常见的exc_bad_access错误的原因。我们需要确保在释放内存之后不再访问已释放的内存。可以使用工具如Instruments来检测内存泄漏和野指针。 5. 使用ARC(自动引用计数):如果我们的应用程序使用了手动管理内存,那么我们应该考虑迁移到ARC来减少内存管理错误的发生。ARC会自动处理内存释放,从而降低了内存相关的问题。 6. 避免循环引用:循环引用也可能导致exc_bad_access错误。我们应该小心使用强引用和弱引用,以避免循环引用的产生。 7. 更新代码库和依赖项:如果我们使用的是第三方库或依赖项,那么我们应该确保它们是最新的版本并且与我们应用程序的其他部分兼容。有时,exc_bad_access错误可能是由于库或依赖项的错误导致的。 总之,解决exc_bad_access错误需要仔细检查代码和内存管理,并根据具体情况进行调试和修复。通过遵循上述步骤,我们可以更好地理解问题并找到适当的解决方案。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值