解释iPhone崩溃日志/堆栈跟踪 [英] Interpreting iPhone Crash Log / Stack Trace

问题描述

我正在使用 TestFlight SDK ，并且收到了一些与此崩溃报告相同的崩溃报告。但是，我很难理解它，崩溃的根本原因是来自报告吗？

I'm using the TestFlight SDK and have received several crash reports identical to this one. However, I'm having trouble understanding it, and what the underlying cause of the crash is from the reports?

Exception

SIGSEGV
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
3 Foundation 0x33750d1c -[NSError dealloc] + 60...

Exception reason

SIGSEGV

Stacktrace

0 MyAppName 0x0013faba testflight_backtrace + 382
1 MyAppName 0x00140708 TFSignalHandler + 264
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
3 Foundation 0x33750d1c -[NSError dealloc] + 60
4 libobjc.A.dylib 0x39230488 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 168
5 CoreFoundation 0x31de9440 _CFAutoreleasePoolPop + 16
6 Foundation 0x33751f7a -[NSAutoreleasePool drain] + 122
7 CoreData 0x35e0a4b2 -[NSManagedObjectContext save:] + 1210
8 MyAppName 0x000b7168 MR_swapMethodsFromClass + 18076
9 CoreData 0x35e0dbc0 developerSubmittedBlockToNSManagedObjectContextPerform + 88
10 libdispatch.dylib 0x335974b6 _dispatch_client_callout + 22
11 libdispatch.dylib 0x33598dca _dispatch_main_queue_callback_4CF$VARIANT$up + 226
12 CoreFoundation 0x31e79f3a __CFRunLoopRun + 1290
13 CoreFoundation 0x31decebc CFRunLoopRunSpecific + 356
14 CoreFoundation 0x31decd48 CFRunLoopRunInMode + 104
15 GraphicsServices 0x36e092ea GSEventRunModal + 74
16 UIKit 0x320db2f8 UIApplicationMain + 1120
17 MyAppName 0x00099122 main (main.m:17)
18 MyAppName 0x000990d7 start + 39

其他详细信息：

• 用户报告该崩溃发生在应用启动后1-2秒


• 该应用使用了Core Data，并且 MagicalRecord （这是MR_swapMethodsFromClass方法的来源）


• 从Xcode（iPhone 3GS，iPhone 4）运行时，我无法在任何测试设备上重现此问题或iPhone 5）运行各种iOS版本（iOS 5.1、6.0、6.1）

• Users report this crash happens 1-2 seconds after the app starts
• The app uses Core Data and MagicalRecord (which is where the MR_swapMethodsFromClass method comes from)
• I can't reproduce this issue on any test devices when running from Xcode (iPhone 3GS, iPhone 4, or iPhone 5) running various iOS versions (iOS 5.1, 6.0, 6.1)

编辑

仍在努力解决这个问题...我已经能够重新创建它（但没有连接调试器）。

Still working on solving this issue... I've been able to recreate it (but not with a debugger attached).

这是最奇怪的部分-如果用户拥有较旧版本的应用程序并安装了更新（通过Test Flight分发），则会收到此错误。

Here's the strangest part-- if a user has an older version of the app and installs an update (distributed via Test Flight), they get this error.

但是，如果他们先删除了旧应用程序并安装更新，不会发生错误。

However, if they first delete the old app and install the update, the error doesn't occur.

推荐答案

让我们逐步了解一下：

0 MyAppName 0x0013faba testflight_backtrace + 382
1 MyAppName 0x00140708 TFSignalHandler + 264

那是TestFlight。

That's TestFlight. This is after the crash has happened, so it's certainly not the cause.

2 libsystem_c.dylib 0x32862e92 _sigtramp + 42

这是我们捕获崩溃的地方。 sigtramp是信号蹦床。这是一种奇特的说法：我抓到一个信号（崩溃），现在我要跳到代码中的其他地方。

This is the point at which we caught the crash. "sigtramp" is the signal "trampoline." That's a fancy way of saying "I caught a signal (crash) and now I'm going to bounce to somewhere else in the code."

3 Foundation 0x33750d1c -[NSError dealloc] + 60

啊。这个很重要。取消分配 NSError 时发生崩溃。这意味着 NSError 被过度释放或保留不足。

Ah. This is important. We crashed while deallocating an NSError. That means the NSError was over-released or under-retained.

4 libobjc.A.dylib 0x39230488 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 168
5 CoreFoundation 0x31de9440 _CFAutoreleasePoolPop + 16
6 Foundation 0x33751f7a -[NSAutoreleasePool drain] + 122

$ b

悲伤...它在耗尽自动释放池时显示。这意味着实际的错误距离这里还有很长的路要走。但是至少我们知道对象的类型。 NSZombies可以用来尝试查找特定对象。

Sad… it manifested while draining the autorelease pool. That means the actual bug could be a long way from here. But at least we know the type of the object. NSZombies could be of use to try to find the specific object.

7 CoreData 0x35e0a4b2 -[NSManagedObjectContext save:] + 1210

在MOC保存期间，自动释放池正在耗尽。这表明它可能与您的核心数据代码有关。

And the autorelease pool was draining during a MOC save. That suggests it's probably related to your Core Data code. It's at least where you'd look first.

要记住的事情是：

• 该错误几乎可以肯定


• 如果不在代码中，则可能在Magical Record中。


• 不要以为它在核心数据中。对于给定的堆栈，这是最不可能出现此错误的地方。

这是最奇怪的部分-如果用户有一个旧版本的应用程序并安装更新（通过Test Flight分发），就会出现此错误。

Here's the strangest part-- if a user has an older version of the app and installs an update (distributed via Test Flight), they get this error.

但是，如果他们先删除旧应用程序并安装更新，则错误不会

However, if they first delete the old app and install the update, the error doesn't occur.

然后可能在您的升级代码中。最有可能在Core Data迁移中。审核该代码区域中 NSError 的每次使用。消除所有编译器和分析器警告。如果可重现，请尝试使用NSZombies。

Probably in your upgrade code then. Most likely in the Core Data migration stuff. Audit every use of NSError in that area of code. Eliminate all compiler and analyzer warnings. And try NSZombies if its reproducible.

这篇关于解释iPhone崩溃日志/堆栈跟踪的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！