iOS野指针定位总结

成因

野指针就是指向一个已删除的对象或者受限内存区域的指针。
我们写C++的时候强调指针初始化为NULL,强调用完后也为其赋值为NULL,谁分配的谁回收,来避免野指针的问题。
比较常见的就是这个指针指向的内存,在别处被回收了,但是这个指针不知道,依然还指向这块内存。
MRC 时代因为引用计数手动控制,所以内存很容易在别处被回收。ARC解决了大部分这种问题。、
在iOS9之前,系统库的delegatetarget-action有一部分是assign(unsafe_unretain)的形式,这时候如果内存在别处被回收了,也是会出现野指针的。
所以iOS9之后这些地方就改成了weak内存修饰符,内存被回收的时候通过weak表,把这些指针设为nil。也大幅度减少了野指针的出现。

如果现在在工程中依然频繁出现野指针,几乎可以肯定是错误地使用了内存。

表现:Crash

对于MachUnixNSException三种不同层级的crash,NSException比较好说,可以直接定位到OC代码。问题主要来自EXC_BAD_ACCESS(SIGSEGV)这种异常,难以在我们的应用代码中定位。

image
  • SIGILL 执行了非法指令,一般是可执行文件出现了错误
  • SIGTRAP 断点指令或者其他trap指令产生
  • SIGABRT 调用abort产生
  • SIGBUS 非法地址。比如错误的内存类型访问、内存地址对齐等
  • SIGSEGV 非法地址。访问未分配内存、写入没有写权限的内存等
  • SIGFPE 致命的算术运算。比如数值溢出、NaN数值等

实际我们遇到Mach Exception绝大部分都是野指针的问题。SIGSEGV/SIGABRT/SIGTRAP 比较多见。
野指针问题表现千奇百怪,而且因为崩溃的地方并不是造成野指针的地方,而且难以重现,所以问题往往难以定位。

image

腾讯Bugly的这张图可以看到,野指针几乎可以造成各种类型的Mach Exception

定位工具

Zoombie Object

这是目前帮助最大的调试模式。实现原理就是 hook 住了对象的dealloc方法,通过调用自己的__dealloc_zombie方法来把对象进行僵尸化。

id object_dispose(id obj)
{
    if (!obj) return nil;

    objc_destructInstance(obj);    
    free(obj);

    return nil;
}

正常的对象释放方法如上,但是僵尸对象调用了objc_destructInstance后就直接return了,不再free(obj);。同时生成一个"_NSZombie_" + clsName类名,调用objc_setClass(self, zombieCls);修改对象的 isa 指针,令其指向特殊的僵尸类。
如果这个对象再次收到消息,objc_msgsend的时候,调用abort()崩溃并打印出调用的方法。

野指针指向的内存没有被覆盖的时候,或者被覆盖成可以访问的内存的时候,不一定会出现崩溃。这个时候向对象发送消息,不一定会崩溃(可能刚好有这个方法),或者向已经释放的对象发送消息。 但是如果野指针指向的是僵尸对象,那就一定会崩溃了,会崩溃在僵尸对象第一次被其它消息访问的时候。

Zombie Object without Xcode

僵尸对象必须在连接Xcode中debug的时候使用,如果我们想跟我们的崩溃收集工具集成在一起,就需要自己实现类似Zombie Object的东西。
逻辑是通过hook住NSObject的根类的dealloc方法,然后在新的dealloc方法中将本来即将释放的对象的isa指针改为指向我们创建的一个新的僵尸类。

iOS使用代码排查野指针错误
开发自己的NSZombie这两篇文章里介绍了在代码里实现类似Zoombie Object的方法,然而实际上是无法使用的,这两种实现跟 Zombie Object 实现上不小的区别,实际应用中有大量误判的情况。

误判的原因主要是dealloc的实现和僵尸类的实现跟Zombie Object不一样。
参考Apple的源码,可以看到Apple是完全调用了objc_destructInstance函数的。而其它人的实现要么没有调用这个函数,要么只做了一部分。对于一个OC对象的dealloc来说,主要包括两部分,一部分是objc_destructInstance,一部分是free(self)objc_destructInstance里包括了移除弱引用,移除关联对象,c++析构等等。这些逻辑不能省略。

- (void)dealloc
{
    const char *className = object_getClassName(self);
    char *zombieClassName = NULL;
    do {

        //...
        Class zombieClass = objc_getClass(zombieClassName);

        objc_destructInstance(self); //关键

        object_setClass(self, zombieClass);

    } while (0);

    if (zombieClassName != NULL)
    {
        free(zombieClassName);
    }
}

而对于僵尸类的实现,Zombie Object的实现简洁而且有效。不像其它人的实现那么臃肿。就只是申明了一个没有任何方法的根类而已,所以任何消息发给它都会crash。

NS_ROOT_CLASS
@interface _NSZombie_ {
    Class isa;
}

@end

所以我从Apple的源码中提取出来的一套实现NSZombie,跟Zombie Object的实现保证完全一致,解决误判的情况。

Scribble

Scribble 工具能够在alloc的时候填上0xAA,dealloc的时候填上0x55,就是对象释放后在内存上填上不可访问的数据,如果再次访问对象就会必现crash。

Bugly的这篇文章如何定位Obj-C野指针随机Crash 就是采用这种方式提高crash率,来方便定位问题。
为了不限制在xcode中使用,自己在代码中实现了类似的逻辑。通过fishhook去hook free函数的方法,实现如下:

void safe_free(void* p){
    size_tmemSiziee=malloc_size(p);
    memset(p,0x55, memSiziee);
    orig_free(p);
    return;
}

虽然已经给被释放的对象写上了0x55,但是如果是内存在被访问(触发crash)之前被其它覆盖了,则可能无法触发crash。 这种情况也不少见。 所以Bugly为了内存不被覆盖,就不再调用free来释放这个内存。保持这个内存一直在。 这样的原理就非常类似Zombie Object了。

制造crash的方式也是采用修改rsa指针的方式,当对象收到消息的时候abort()。

Address Sanitizer

malloc/free函数进行了替换。在malloc函数中额外的分配了禁止访问区域的内存。 在free函数中将所有分配的内存区域设为禁止访问,并放到了隔离区域的队列中(保证在一定的时间内不会再被malloc函数分配)。 如果访问到禁止访问的区域,就直接crash。

对CPU影响2~5⨉, 增加内存消耗 2~3⨉。

能够检查出来的问题:

  • 访问已经dealloc的内存/dealloc已经dealloc的内存
  • dealloc还没有alloc的内存(但不能检查出访问未初始化的内存)
  • 访问函数返回以后的栈内存/访问作用域之外的栈内存
  • 缓冲区上溢出或下溢出,C++容器溢出(但不能检查integer overflow)

不能用于检查内存泄漏。有些文章说ASan能检查内存泄漏是不对的,Google的LSan可以,但是Xcode的Asan不行。

Malloc Stack

之前介绍的工具都是提高崩溃概率,以拿到崩溃的对象和内存地址。拿到崩溃的对象之后也很难定位,因为崩溃地方离释放的地方已经很远了。而且有些对象在工程中初始化了很多个,不知道是对应的哪个地方出了问题。所以如果能知道对象是在哪初始化的就好了。
Malloc Stack 能够记录下来所有对象的malloc调用时的堆栈信息。然后我们执行命令:

script import lldb.macosx.heap
malloc_info --stack-history 0x7fbf0dd4f5c0

就可以在lldb中打印出来该对象初始化位置的堆栈信息。
Malloc Stack但是有两个巨大的缺点,一个是只能在模拟器上使用,第二是没有打印出dealloc的信息。如果想在真机上使用需要越狱。

lzMalloc

公司内部的大神开发的的lldb插件,基于Malloc Stack开发的,通过调用私有函数拿到Malloc Stack记录的数据。能够支持真机调试,能够打印出dealloc的堆栈信息。
能打印出dealloc的原因是hook了-dealloc方法,调用__disk_stack_logging_log_stack函数记录当前的堆栈信息。

几个野指针的例子

错误的内存修饰符

遇到的这个例子可能是比较经典的野指针,崩溃日志中出现了各种各样的表现。

第一种表现是dealloc对象时崩溃:

0 libsystem_kernel.dylib 0x252fac5c __pthread_kill + 4
1 libsystem_c.dylib 0x2528f0ac abort + 103
2 libsystem_malloc.dylib 0x25324ef6 free + 431
3 libobjc.A.dylib 0x24e13e08 object_dispose + 19
4 Foundation 0x25de3cf2 -[NSIndexPath dealloc] + 66
5 libobjc.A.dylib 0x24e24f66 objc_object::sidetable_release(bool) + 150
6 libsystem_blocks.dylib 0x25243ac2 _Block_release + 215
7 CoreFoundation 0x25583384 -[__NSArrayI dealloc] + 64
5 libobjc.A.dylib 0x24e24f66 objc_object::sidetable_release(bool) + 150
9 UIKit 0x29e934f2 __runAfterCACommitDeferredBlocks + 310
10 UIKit 0x29e9f7da __cleanUpAfterCAFlushAndRunDeferredBlocks + 90
11 UIKit 0x29bddb1c __afterCACommitHandler + 84

可以看到这里完全是系统library的崩溃,跟工程代码毫无关系,最开始也是一头雾水。
这里只有两个线索,一个是NSIndexPath,另一个是只发生于10.3.3之前的iphone5机型上。
因为10.3.3是iphone5支持的最后一个版本,所以用户量并不少。

第二种表现是objc_msgsend, isEqual:是通过读取ARM寄存器lr获取到的方法名,这个是Bugly帮我们查到的。

0 libobjc.A.dylib 0x1a1b0dd6 objc_msgSend (isEqual:) + 15
1 UIKit 0x201afdfa -[UICollectionReusableView _setLayoutAttributes:] + 60
2 UIKit 0x209d0280 -[UICollectionView _applyLayoutAttributes:toView:] + 138
3 UIKit 0x209daf26 ___88-[UICollectionView _dequeueReusableViewOfKind:withIdentifier:forIndexPath:viewCategory:]_block_invoke + 28
4 UIKit 0x2015b5c2 +[UIView(Animation) performWithoutAnimation:] + 84
5 UIKit 0x209dae40 -[UICollectionView _dequeueReusableViewOfKind:withIdentifier:forIndexPath:viewCategory:] + 2156
6 UIKit 0x201af68a -[UICollectionView dequeueReusableCellWithReuseIdentifier:forIndexPath:] + 160
7 XXXXXXProject 0x00404c02 -[XXXXXXCollectionView collectionView:cellForItemAtIndexPath:] (XXXXXXClass.m:77)
8 UIKit 0x209cf850 -[UICollectionView _createPreparedCellForItemAtIndexPath:withLayoutAttributes:applyAttributes:isFocused:notify:] + 420
9 UIKit 0x201af5e0 -[UICollectionView _createPreparedCellForItemAtIndexPath:withLayoutAttributes:applyAttributes:] + 42
10 UIKit 0x201ad7f6 -[UICollectionView _updateVisibleCellsNow:] + 4076
11 UIKit 0x201a83d6 -[UICollectionView layoutSubviews] + 398
12 UIKit 0x2014b482 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1224

这里线索就比较丰富,可以找到对应的类了,XXXXXXProject 是我们的工程,明显崩溃在UICollectionView中。在重用collectionViewCell的过程中,调用_setLayoutAttributes 的方法,在+60的位置调用了isEqual:,经过反编译这个方法得知调用isEqual:的对象的是UICollectionViewLayoutAttributes(反编译过程省略)。
这里也是只发生于10.3.3之前的iphone5机型上。所以基本确定是同一个问题。

但是并没有什么了卵用,正如之前所说的,野指针崩溃的地方跟出错的地方相去甚远。
唯一能确定的地方,就是引起崩溃的对象是NSIndexPath

第三种表现比较奇怪,报[UITransitionView initialize] unrecognized selector,这个类一脸懵逼。不知道在哪使用过

Exception Type: NSInvalidArgumentException(SIGABRT)
Exception Codes: -[UITransitionView initialize]: unrecognized selector sent to instance 0x165f22c0 at 0x1c4d1acc
Crashed Thread: 0
0 CoreFoundation 0x1cd03b3d ___exceptionPreprocess + 129
1 libobjc.A.dylib 0x1bf8b067 objc_exception_throw + 31
2 CoreFoundation 0x1cd08fd1 ___methodDescriptionForSelector + 1
3 CoreFoundation 0x1cd070c3 ____forwarding___ + 697
4 CoreFoundation 0x1cc2fdc8 _CF_forwarding_prep_0 + 24
5 libobjc.A.dylib 0x1bf8bbad _CALLING_SOME_+initialize_METHOD + 23
6 libobjc.A.dylib 0x1bf8bdf3 __class_initialize + 579
7 libobjc.A.dylib 0x1bf92c15 _lookUpImpOrForward + 173
8 libobjc.A.dylib 0x1bf92b65 __class_lookupMethodAndLoadCache3 + 27
9 libobjc.A.dylib 0x1bf991af __objc_msgSend_uncached + 15
10 UIKit 0x21f98167 -[UICollectionViewLayoutAttributes isEqual:] + 95
11 UIKit 0x21f97dfb -[UICollectionReusableView _setLayoutAttributes:] + 61
12 UIKit 0x227b8281 -[UICollectionView _applyLayoutAttributes:toView:] + 139
13 UIKit 0x227c2f27 ___88-[UICollectionView _dequeueReusableViewOfKind:withIdentifier:forIndexPath:viewCategory:]_block_invoke + 29
14 UIKit 0x21f435c3 +[UIView(Animation) performWithoutAnimation:] + 85
15 UIKit 0x227c2e41 -[UICollectionView _dequeueReusableViewOfKind:withIdentifier:forIndexPath:viewCategory:] + 2157
16 UIKit 0x21f9768b -[UICollectionView dequeueReusableCellWithReuseIdentifier:forIndexPath:] + 161

看下面的堆栈就发现还是同一个问题,但是为啥会报这么奇怪的错? 这就是野指针的表现。这一块内存被别的东西覆盖了。

实际上还有其它的表现,但是比较具有代表性的就这三个了。从崩溃日志中只能得到有限的信息,一个是这个是野指针问题。第二个是这个野指针对象很可能是一个NSIndexPath对象(也不能完全确定)。

如果不知道是野指针的问题,就很容易误入歧途,花大量时间在研究UICollectionView 或者在研究UITransitionView上。其实都是浪费时间,因为造成野指针的地方地方已经很远了。

正如Bugly这篇文章说的,定位野指针最重要还是增大野指针出现的概率。 所以这次我是采用Zombie Object,并且限制在iPhone5 和 iOS10.3.3的情况下重现的。

经过多次重现,确定了是NSIndexPath的问题,而且所有的UICollectionViewUITableView都受到了影响。所以我开始怀疑是不是工程中有全局的代码被hook了。果然不出所料:

- (void)forwardInvocation:(NSInvocation *)invocation
{
    [invocation invokeWithTarget:self.target];
    if (kiOS9Later) {
        if ([NSStringFromSelector(invocation.selector) isEqualToString:@"collectionView:didSelectItemAtIndexPath:"]) {
            //无痕打点
            __unsafe_unretained UICollectionView *collectionView = nil;
            id indexPath;
            [invocation getArgument:&collectionView atIndex:2];
            [invocation getArgument:&indexPath atIndex:3];
            [FPPVHelper reportMTAEventId:[collectionView hotTagId] Index:[indexPath row] info:nil];
        }
    }
}

这是某一段神奇的打点代码,不知道谁写的。很明显indexPath此处的修饰符应为__unsafe_unretained,如果为strong的话对象在这里就会被ARC释放掉,然而因为传递的是C指针,其它地方的某个指针不知道这里释放了,依然指向了这里。产生了野指针。

iOS9之前的delegate 崩溃

在iOS9之前的tableview的delegate和datasource都是assign内存修饰符的。iOS9之后才使用weak

// iOS 8 之前
@property(nonatomic, assign) id<UITableViewDataSource> dataSource
@property(nonatomic, assign) id<UITableViewDelegate> delegate
// iOS 9 之后
@property(nonatomic, weak, nullable) id<UITableViewDataSource> dataSource
@property(nonatomic, weak, nullable) id<UITableViewDelegate> delegate

这种情况,如果delegatetableview本身更早被释放,此时的dataSource就会成为一个野指针。常见的情况比如block调用延长了tableview的生命周期,就可能会发生这种情况,导致野指针crash。 一般崩溃日志里是objc_msgsend + 15 的崩溃,崩溃在delegate或者datasource的方法里。

解决方法也很简单,在dealloc的时候把dataSource和delegate设为nil即可。

- (void)dealloc
{
    _tableView.delegate = nil;
    _tableView.dataSource = nil;
}

iOS9 之前的target-action崩溃

崩溃堆栈也是最常见的objc_msgSend,这里可以看到是工程中hook的某个方法崩溃了

libobjc.A.dylib objc_msgSend (pv_gestureRecongizerAction:)
UIKit -[UIGestureRecognizer _updateGestureWithEvent:buttonEvent:]
UIKit ____UIGestureRecognizerUpdate_block_invoke662
UIKit __UIGestureRecognizerRemoveObjectsFromArrayAndApplyBlocks
UIKit __UIGestureRecognizerUpdate
SEGV_ACCERR

我们自己的代码如下,就是在addGestureRecognizer方法中加了一层调用,加了一层target-action。这相当于是给gestureRecognizer加了两个target-action

-(void)pv_addGestureRecognizer:(UIGestureRecognizer *)gestureRecognizer {
    [gestureRecognizer addTarget:self action:@selector(pv_gestureRecongizerAction:)];
    [self pv_addGestureRecognizer:gestureRecognizer];
}

由于target对于gesture来说在iOS8上也是类似assign的,所以这里就是self被释放了,变成野指针了,但是gestureRecognizer的target依然指向了self的内存。 当self已经被释放了,但是gestureRecognizer还没被释放的时候就会发生这种情况。

总结

野指针定位有几个关键:

  • 第一是意识到这是野指针的问题:Mach Exception大多数都是野指针的问题,崩溃日志里最多见objc_msgSendunrecognized selector sent to等等。而且往往跟iOS SDK版本和iphone型号有关。 认识到野指针的问题后,就不必要拘泥于崩溃日志,因为崩溃的地方离崩溃的原因比较远了。
  • 第二是尽可能重现。利用Zombie Object/Scribble/Aasn 都可以。个人认为自己实现的Zombie Object最好,既可以脱离Xcode debug的限制,使用又比较简单。
  • 第三是根据野指针指向的对象来判断出错的位置,而不是崩溃的方法。因为崩溃的方法离崩溃的原因比较远了,但是野指针指向的对象多半还是出错的对象(有时也可能被覆盖了)。
  • 第四是利用malloc stack/lzMalloc找到野指针指向对象初始化的位置和dealloc的位置,判断是否过早释放等。
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,688评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,559评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,749评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,581评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,741评论 3 271
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,684评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,122评论 2 292
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,847评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,441评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,939评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,333评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,783评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,275评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,830评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,444评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,553评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,618评论 2 249