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

【问题标题】：objc_msgSend [__NSArrayM dealloc] crash report sometimes from Crashlyticsobjc_msgSend [__NSArrayM dealloc] 有时来自 Crashlytics 的崩溃报告
【发布时间】：2015-09-01 16:37:29
【问题描述】：

我最近在更新到 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

【问题讨论】：

它是否始终可重复？在我看来，您正在尝试访问已释放的 NSArray 实例。
@remus 不经常。但今天我收到了来自这次崩溃的 2 份报告，这很奇怪。以前版本的应用还没有生产出来。
是在调试器中发生，还是仅在生产应用商店版本中发生？
@remus 我不确定，但我从未在我的测试设备（开发）上遇到过这个错误。
我看到了同样的崩溃。在我查看的所有日志中，这都是在发布后不久发生的。 100% 的崩溃发生在 iOS 8 上（尽管大多数用户使用的是 8）。这也是我使用更新的 Fabric/Crashlytics 框架的第一个版本。我通过对整个项目的 grepping 确认我没有弱 NSMutableArray 属性、ivars 或局部变量。同样，丧尸仪器也没有出现任何东西。到目前为止，我还没有真正的线索。

标签： ios objective-c crashlytics twitter-fabric

【解决方案1】：

您的 NSArray 似乎已发布并且您想访问它，因此发生了此崩溃。您可以在模型或 VC 中将 NSArray 定义为 Strong

@property(nonatomic, strong) NSArray *myArray

如果你猜不出哪个 NSArraY 已经发布，我建议你在工具中使用 NSZombie 对象调试你的应用程序以找到准确的 NSArray

【讨论】：

问题是我无法重现它
我建议您在日志中设置最后一个视图控制器的名称（使用 fabric - crashlytics）以发送崩溃报告以查找发生在哪个类中。我知道找到这种崩溃的原因很难，但这是找到它的最佳方法
我做到了，但这次崩溃并没有发送视图控制器的名称。它说它发生在 main.h

【解决方案2】：

它发生在我身上很多次。只需为代码中的每个NSArray 添加强引用。然后您将永远不会看到您所看到的错误。

最好使用下面的代码：

@property(strong) NSArray *myArray.

【讨论】：

【解决方案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

【讨论】：

感谢您的详细回答。在 ARC 项目中可能导致这种情况的原因是什么？我不会手动向项目中的任何对象发送发布或自动发布。这个崩溃是在一个相当小的更新之后出现的，我在提交中没有看到任何可疑的东西。
@Alex 嗯，很难说。它可以重现吗？这可能是时间问题。
根本无法重现。我自己从未亲眼目睹过这种崩溃。我最后一次看到它在数千次会话中发生了 47 次。从日志中我可以看到它总是在发布后不久发生。
@Alex 您应该检查两件具体的事情 - 1. 由于设备越狱而发生了一些奇怪的崩溃 2. 人们已经开始安装 iOS 9 测试版。尝试找出问题是否与 iOS 9 无关。
与@Alex 相同。我正在使用 ARC，崩溃日志来自 iOS8。

【解决方案4】：

原来是框架的bug

这是我从 Crashlytics 的支持中得到的结果

如果您更新到 Crashlytics SDK 的 3.0.10，这一切都应该设置好了 - 我们用最新版本修补了 3.0.9 中的罕见竞争情况。打开 Fabric.app，更新框架，一切顺利:)

Crashlytics 的支持团队很棒！

【讨论】：

谢谢。一直在寻找造成这种情况的原因，并且刚刚来到 Crashlytics！如果他们联系在 3.0.9 上遇到此错误的开发人员让他们知道，这可能会很有用！
@MRNeilM 那会非常好，或者至少在 Answers 仪表板上有一点警告，“嘿，如果您使用的是 Crashlytics 3.0.9，则会出现崩溃问题”。我在 Fabric 发布时向 Fabric 提出了功能请求，以获取 RSS 提要或发布说明的电子邮件。我希望他们至少可以做到这一点，以便您知道新的 Crashlytics SDK 何时发布。
@PolarBear 完全同意。我刚刚发布了更新，所有崩溃都停止了。
看起来这个问题在 3.7.2 版本中又出现了

【解决方案5】：

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

已更新至 Crashlytics 3.0.10，并在周六进行了紧急更新。结果不言自明：

从周一的 99.9% 无崩溃率下降到周二发布的更新，到 6 月 26 日周五，无崩溃率下降至 98.3%，经历崩溃的用户增加了 16 倍以上。 6 月 27 日星期六，我让 Apple 进行了加急的 App Review，并且带有 Crashlytics 3.0.10 的新版本于星期六在 App Store 中发布。如您所见，在发布后的几天内，无崩溃率现在又回到了 99%，回到了 99.9%。

我希望这对那些因崩溃框架引起的崩溃而烦恼的人有所帮助。至少他们很快解决了这个问题，新版本似乎完全解决了这个问题。

【讨论】：

这正是我今天在仪表板中看到的。