让我们来看看：
0 MyAppName 0x0013faba testflight_backtrace + 382
1 MyAppName 0x00140708 TFSignalHandler + 264
这就是测试飞行。这是事故发生之后的事，所以这肯定不是事故原因。
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
这是我们发现崩溃的时刻。 “sigtramp”是信号“trampoline”。这是一种奇特的说法，“我捕获了一个信号（崩溃），现在我要跳到代码中的其他地方”。
3 Foundation 0x33750d1c -[NSError dealloc] + 60
啊。这个很重要。我们在取消分配时崩溃了NSError。这意味着NSError被过度释放或保留不足。
4 libobjc.A.dylib 0x39230488 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 168
5 CoreFoundation 0x31de9440 _CFAutoreleasePoolPop + 16
6 Foundation 0x33751f7a -[NSAutoreleasePool drain] + 122
悲伤……它在耗尽自动释放池时显现出来。这意味着实际的错误可能离这里很远。但至少我们知道对象的类型。 NSZombies 可用于尝试查找特定对象。
7 CoreData 0x35e0a4b2 -[NSManagedObjectContext save:] + 1210
并且在 MOC 保存期间自动释放池正在耗尽。这表明它可能与您的核心数据代码有关。至少这是您首先看到的地方。
要记住的事情是：
- 该错误几乎肯定存在于您的代码中。
- 如果它不在你的代码中，它可能在 Magical Record 中
- 不要假设它在核心数据中。考虑到这个堆栈，这是最不可能出现错误的地方。
这是最奇怪的部分 - 如果用户拥有旧版本的应用程序并安装更新（通过 Test Flight 分发），他们会收到此错误。
但是，如果他们首先删除旧应用程序并安装更新，则不会发生错误。
可能在你的升级代码中。最有可能是在核心数据迁移方面。审核每次使用NSError在该代码区域。消除所有编译器和分析器警告。如果它可以重现，请尝试 NSZombies。
