iOS开发-EXC_BAD_ACCESS崩溃的本质

1.野指针的危害

我们知道在OC中向nil指针发送消息是不会导致崩溃的。但是我们向一个已经标记删除的内存地址发送消息就很容易出现问题。就像是绿灯的时候过马路是安全的,但是闯红灯就很容易出事故,但是并不是每次闯红灯都会出现事故,所以这类的野指针问题比较难查找和复现。

2.如何定位野指针问题

错误类型

野指针可能造成的问题.png

2.1 使用Xcode僵尸模式 ( NSZombieEnabled )

Product -> Scheme -> Edit Scheme -> Diagnostics -> 勾选Zombie Objects

Product -> Scheme -> Edit Scheme -> Arguments设置NSZombieEnabled、MallocStackLoggingNoCompact两个变量,且值均为YES。

仅设置Zombie Objects的话,如果Crash发生在当前调用栈,系统可以把崩溃原因定位到具体代码中;但是如果Crash不是发生在当前调用栈,系统仅仅告知崩溃地址,所以我们需要添加变量MallocStackLoggingNoCompact,让Xcode记录每个地址alloc的历史,然后通过命令将地址还原出来。

Xcode 6之前还可以使用gdb,可以使用info malloc-history address命令来将发生崩溃的地址还原成具体的代码行,Xcode 7之后只能使用lldb,使用命令bt来打印调用堆栈。

在启用僵尸对象后,在运行期发现 testObject 变成了僵尸对象,那么便动态的创建一个 _NSZombie_testObject 类,将 testObject 对象的 isa 指针指向这个新的类,再次向 testObject 对象发消息的话就会去 _NSZombie_testObject 这个类里去找相应的方法,然而 _NSZombie_testObject 这个类没有实现任何方法,那么发给他的全部消息都要经过“完整的消息转发机制”。在发生崩溃的栈回溯消息能能看到 forwarding 函数,该函数首先要做的事情就是检查接受对象所属的类名,如果类名前缀为 NSZombie,则表明消息接收者是僵尸对象,那么会在控制台打印一条消息。将消息接受对象所属的类名去掉 NSZombie 前缀就能得到原始类名了。

2.2 使用Address Sanitizer 地址消毒剂(洗手液)

Address Sanitizer是基于LLVM的适用于C(包括Objective-C)和Swift的用于发现内存使用问题的工具。

Address Sanitizer的原理
启用Address Sanitizer后,会在APP中增加libclang_rt.asan_ios_dynamic.dylib,它将在运行时加载。

Address Sanitizer替换了malloc和free的实现。当调用malloc函数时,它将分配指定大小的内存A,并将内存A周围的区域标记为off-limits。当free方法被调用时,内存A也被标记为off-limits,同时内存A被添加到隔离队列,这个操作将导致内存A无法再被重新malloc使用。代码中所有的内存访问操作都被编译器转换为如下形式:

// Before
*address = ...;  // or: ... = *address;

// After
if (IsMarkedAsOffLimits(address)) {
  ReportError(address);
}
*address = ...;  // or: ... = *address;

当访问到被标记为off-limits的内存时,Address Sanitizer就会报告异常。

Address Sanitizer可以用来检测如下内存使用错误:

  • 内存释放后又被使用;
  • 内存重复释放;
  • 释放未申请的内存;
  • 使用栈内存作为函数返回值;
  • 使用了超出作用域的栈内存;
  • 内存越界访问;

也可以通过命令行的方式启用Address Sanitizer:

  • clang
    -fsanitize=address

  • swiftc
    -sanitize=address

  • xcodebuild
    -enableAddressSanitizer YES

Address Sanitizer的使用限制:

  • Address Sanitizer是运行时的能力,代码只有被运行到了才能检测出内存问题,而我们无法保证所有的代码分支和逻辑都能执行到,所以检测并不是全面的。Apple 推荐结合单元测试一起使用。

  • Address Sanitizer不能检测内存泄露,访问未初始化的内存或整形溢出。

对性能的影响:开启Address Sanitizer,将使代码执行效率降低2-5倍,内存使用增加2-3倍。可以通过设置-O1优化级别来提高内存利用率。

2.3 使用 Enable Malloc Scribble(涂鸦)

申请内存后在申请的内存上填0xAA,内存释放后在释放的内存上填0x55;
如果内存未被初始化就被访问,或者释放后被访问,就会引发异常,这样就可以使问题尽快暴露出来。

Scribble其实是malloc库libsystem_malloc.dylib自身提供的调试方案

2.4 Enable Malloc Guard Edges

Enable Guard Edges. Add guard pages before and after large allocations.
申请大片内存的时候在前后page上加保护,详见保护模式

2.5 Enable Guard Mallocs

使用libgmalloc捕获常见的内存问题,比如越界、释放之后继续使用。

由于libgmalloc在真机上不存在,因此这个功能只能在模拟器上使用.

参考文章

1.如何定位Obj-C野指针随机Crash(一):先提高野指针Crash率
2.如何定位Obj-C野指针随机Crash(二):让非必现Crash变成必现
3.如何定位Obj-C野指针随机Crash(三):如何让Crash自报家门
4.腾讯Bugly-腾讯云专栏
5.iOS野指针定位总结
6.Understanding EXC_BAD_ACCESS
7.How to Debug an iPhone App Crash
8.极致的技术博客-iOS 崩溃Crash解析
9.iOS Zombie Objects(僵尸对象)原理探索
10.Crash 防护方案(二):EXC_BAD_ACCESS
11.Baymax:网易iOS App运行时Crash自动防护实践
12.Address Sanitizer的原理和使用
13.Xcode 利用工具解决程序内存问题

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 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、付费专栏及课程。

余额充值