有时来自Crashlytics的objc_msgSend [__NSArrayM dealloc]崩溃报告

Question

我最近在更新到Crashlytics 3.0后收到了这个应用程序不确定它是否来自我的代码或其他东西.崩溃报告无法追踪

Here is the crash report

Crashed: com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x000000009a0dbeb8

0   libobjc.A.dylib objc_msgSend + 16 release
1   CoreFoundation  CFRelease + 524
2   CoreFoundation  -[__NSArrayM dealloc] + 152
3   libobjc.A.dylib (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 564
4   CoreFoundation  _CFAutoreleasePoolPop + 28
5   Foundation  -[NSAutoreleasePool release] + 148
6   UIKit   -[UIApplication _run] + 588
7   UIKit   UIApplicationMain + 1488
8   MyAppName   main.m line 32main
9  libdyld.dylib    start + 4

Answer 1

事实证明这是框架工作的错误

这是我从Crashlytics的支持中获得的

如果您更新到Crashlytics SDK的3.0.10,则应该全部设置 - 3.0.9中有一个罕见的竞争条件,我们使用最新版本进行了修补.打开Fabric.app,更新框架,你会很高兴:)

Crashlytics的支持团队非常棒!

Answer 2

确认这是我的应用程序在2015年6月10日发布的Crashlytics 3.0.9中根据https://dev.twitter.com/fabric/overview/changelog发布的.

更新到Crashlytics 3.0.10并在周六推出紧急更新.结果不言自明:

周一发布了99.9%的Crash Free,周二发布了更新,截至6月26日周五,Crash Free率下降到了98.3%,用户遇到了崩溃,增加了16倍.在6月27日星期六,我能够让Apple进行加速App评论,而Crashlytics 3.0.10的新版本于周六发布到App Store.正如您所看到的那样,在发布后的几天内,Crash Free率回到99%,回到99.9%.

我希望这可以帮助那些因你的崩溃框架以外的其他人引入的崩溃而拔出头发的人.至少他们很快就解决了,新版本似乎完全解决了这个问题.

Answer 3

CoreFoundation  _CFAutoreleasePoolPop + 28

自动释放池正在耗尽,可能在UI循环结束时.这意味着池中的所有自动释放对象现在都已释放.

CoreFoundation  -[__NSArrayM dealloc] + 152

正在发布一个可变数组.这意味着它所持有的所有物品也将被释放.

CoreFoundation  CFRelease + 524

阵列中的一个项目正在发布.

崩溃,该项无效,已被解除分配.

你应该检查的东西是数组中的项目.有些东西肯定是过度发布的.如果使用手动引用计数,则应检查放入数组的对象 - 其中一个项目已取消分配但仍保留在某个数组中.

在MRC下触发类似错误的代码如下:

NSMutableArray *array = [NSMutableArray array]; //an autoreleased array
NSObject *object1 = [[NSObject alloc] init];
NSObject *object2 = [[NSObject alloc] init];

[array addObject:object1]    
[array addObject:object2]    

[object1 release];
[object2 release];

//let's overrelease
[object1 release];
//when array is released, it will send a release message to object1, too