32bit设备上关于NSNumber的一个大坑以及OBJC_ASSOCIATION_ASSIGN可能引起的Crash

问题现象:

<br />有这样两个方法:

- (ErrorViewType)viewType {
    NSNumber *number = objc_getAssociatedObject(self, @selector(viewType));
    return [number integerValue];
}
 
l
- (void)setViewType:(ErrorViewType)viewType {
    objc_setAssociatedObject(self, @selector(viewType),@(viewType), OBJC_ASSOCIATION_ASSIGN) ;
}

其中ErrorViewType为枚举变量类型NSUInteger,值为0-14

有这样两个方法,某一次setViewType传入的值为14,但是在之后某次get的时候直接崩了。报的错误是EXC_BAD_ACCESS,即野指针访问,那么这个对象又是什么时候被释放,又为什么被释放了呢?

写了一个简单的Demo在32bit真机上验证了一下,iPhone4s,iOS7系统:

crash截图.png

可见当被关联的对象NSNumer的值为13的时候,在下一轮runloop去访问这个对象会引发野指针访问:
编译器的代码大概是,通过rewrite以及汇编代码整理:

id tmp1 = _objc_retainAutoreleasedReturnValue([NSNumber numberWithInt:13]);//ARC环境下对于autorelease对象的优化 这个时候tmp1指向的对象retainCount为1
_objc_setAssociatedObject(self,_SEL(testMagicNumber),tmp1,0);
_objc_release(temp1);//因为temp是作为一个入参压栈的,这里出了上面方法的作用域就会被释放
id tmp2 = _objc_retainAutoreleasedReturnValue(_objc_getAssociatedObject(self,_SEL(testMagicNumber)));
objc_storeStrong(&tmp2,nil);//release temp2指向的对象,并且把temp2指向nil

其中对于ARC下对autorelease对象的优化可以参考我上一篇博客:
ARC环境下编译器到底对autorelease对象做了怎样的优化

可见temp1指向的对象在_objc_setAssociatedObject方法调用结束之后就立即被释放了,而对于关联对象的修饰符又是assign,没有被强引用,所以最后temp1指向的对象release1次引用计数就变成了0,也就随即被释放了。所以下一轮runloop访问的时候就引发野指针访问的崩溃了。在当前runloop访问的话也会崩溃,但是如果把上面的set和get方法抽出来之后现象有点诡异,这个待会说。

然后我们把NSNumer的值改为12之后,一切正常, 这其中有什么猫腻呢。

http://stackoverflow.com/questions/2533355/nsnumber-13-wont-retain-everything-else-will
上面这个回答里有提到,NSNumber在32bit设备之上0-12都是存在内存共享区,类似于[NSArray array]无论调用多少次指针指向的都是相同的一块内存区域,永远不会被销毁。而只要大于12就是正常的创建在堆上的对象。为了验证这个问题,再写个Demo,还是4s真机测试:

32bit magic number test

果然,验证了猜想,在iPhone5 iOS10系统上同样的现象。

同时也发现了一个有意思的现象:

封装get方法之后不会崩溃.png

将get操作封装在一个方法中,不会崩溃。这个原因暂时没想通,但是只要点了Xcode的停止按钮,还是会提示有Crash

奇葩的崩溃

在get操作之后再打印一下取到的对象,这种case下就会崩溃,然后取到的对象居然是@(20),也就是虽然@(14)被释放了,但是在他的内存区域由重新new了一个@(20)的对象,鸠占鹊巢,@(20)这个对象被释放之后20这个值还是存在的,所以还能够打印出来,但是因为执行的对象以及被销毁,所以再对其调用release方法就自然会报double free的错误了。

这里到底为什么,一块内存被销毁之后内存中到底是如何标记的,抛砖引玉一下,欢迎大神指导~

那么对于64bit的设备呢?

64bit magic number test1.png
64bit magic number test2.png

可见无论NSInterger保存的这个数有多大,只要在正常范围之内,一定是存放在常量区的,也就是永远不会释放。

可见,是系统在32bit设备上对NSNumber类型的对象做的优化不够彻底,然后我们在使用关联对象时内存修饰符又使用不当,造成了崩溃的问题。猜测对于32bit的设备,同时存在大量的共享内存会比较消耗资源,因此只对0-12这少数的几个数做了优化,而出问题时候我们传入的参数刚好是14,所以就掉进了坑里。

解决办法及结论

OBJC_ASSOCIATION_ASSIGN改为OBJC_ASSOCIATION_RETAIN,这样在本对象有一个强引用,这个被关联的对象也就不会释放,生命周期也和本对象相同了。我认为既然关联对象传入的都是对象,那么其实绝大多时候用的都应该是是OBJC_ASSOCIATION_RETAIN,在我们项目中传入的对象很多是NSNumber类型(包装的bool或则int)的时候都是用的OBJC_ASSOCIATION_ASSIGN,以前没暴露问题也是误打误撞错进错出。所以除了一些需要破解循环引用的场景,关联对象的内存操作修饰符建议都用OBJC_ASSOCIATION_RETAIN

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,185评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,445评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,684评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,564评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,681评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,874评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,025评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,761评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,217评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,545评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,694评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,351评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,988评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,778评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,007评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,427评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,580评论 2 349

推荐阅读更多精彩内容