iPhone Crash堆栈跟踪VS Crash报告

Question

花了一些时间......在崩溃时，却没有理解它。那是经典之作：

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000010

这导致了内存问题，解决了无效地址0x10

困扰我的是我有崩溃报告和堆栈跟踪，它们有所不同：

---

崩溃报告，由用户发送（符号化成功，发生）：

Thread 0 Crashed:
0   libobjc.A.dylib                 0x000027d8 objc_msgSend + 16
1   UIKit                           0x0005e9d2 -[UIViewAnimationState animationDidStop:finished:] + 54
2   QuartzCore                      0x0002d8c2 run_animation_callbacks(double, void*) + 286
3   QuartzCore                      0x0002d764 CA::timer_callback(__CFRunLoopTimer*, void*) + 116
4   CoreFoundation                  0x000567f4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 8
5   CoreFoundation                  0x000562a6 __CFRunLoopDoTimer + 854
6   CoreFoundation                  0x0002779e __CFRunLoopRun + 1082
7   CoreFoundation                  0x00027270 CFRunLoopRunSpecific + 224
8   CoreFoundation                  0x00027178 CFRunLoopRunInMode + 52
9   GraphicsServices                0x000045ec GSEventRunModal + 108
10  GraphicsServices                0x00004698 GSEventRun + 56
11  UIKit                           0x0000411c -[UIApplication _run] + 396
12  UIKit                           0x00002128 UIApplicationMain + 664
13  MyApp                           0x00003158 main (main.m:13)
14  MyApp                           0x00003120 0x1000 + 8480

---

崩溃堆栈跟踪（由异常处理程序捕获）

0   MyApp                               0x000d79c3 0x0 + 883139
1   MyApp                               0x000d790b 0x0 + 882955
2   libSystem.B.dylib                   0x302765d3 _sigtramp + 42
3   UIKit                               0x31eab9d9 -[UIViewAnimationState animationDidStop:finished:] + 60
4   QuartzCore                          0x33a178c9 _ZL23run_animation_callbacksdPv + 292
5   QuartzCore                          0x33a1776b _ZN2CAL14timer_callbackEP16__CFRunLoopTimerPv + 122
6   CoreFoundation                      0x3084e7fb __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 14
7   CoreFoundation                      0x3084e2ad __CFRunLoopDoTimer + 860
8   CoreFoundation                      0x3081f7a5 __CFRunLoopRun + 1088
9   CoreFoundation                      0x3081f277 CFRunLoopRunSpecific + 230
10  CoreFoundation                      0x3081f17f CFRunLoopRunInMode + 58
11  GraphicsServices                    0x31e445f3 GSEventRunModal + 114
12  GraphicsServices                    0x31e4469f GSEventRun + 62
13  UIKit                               0x31e51123 -[UIApplication _run] + 402
14  UIKit                               0x31e4f12f UIApplicationMain + 670
15  MyApp                               0x0000315f 0x0 + 12639
16  MyApp                               0x00003128 0x0 + 12584

两者都不同，堆栈跟踪指向我的代码中的崩溃，但在地址我既不能象征也不能识别。我认为崩溃报告表明已将消息发送到已发布的实例...可能与使用以下内容有关：

+ (void)setAnimationDelegate:(id)delegate
+ (void)setAnimationDidStopSelector:(SEL)selector

所以这里（终于！）是我的问题：

1. 什么解释了日志之间的差异？ （libobjc.A vs libSystem.B ??）
2. SIGBUS是来自我的代码还是来自UIKit？
3. 如何解读堆栈跟踪高位地址（0x000d79 ??，atos无法解析）
4. 这就是我的想法，与动画相关的问题未能结束？与此类似> How to unset delegate on UIView setAnimationDelegate: call?
5. AFAIK，setAnimationDelegate应该保留委托......有人要确认吗？

编辑：我无法使用NSZombiesEnabled，这是来自已发布应用的崩溃报告，这是我无法在开发环境中重现的崩溃。我只是有这些日志来诊断。

Answer 1

每当我在顶部看到objc_msgSend时，我对剩余堆栈的信任度很低，因为给出这个错误的错误会给堆栈带来坏处。

GuardMalloc对此有好处，因为尝试使用解除分配的空间做任何事情都会立即在调试器中使应用程序崩溃。堆栈将完好无损。 （这使得应用程序非常慢，但它是一个非常强大的工具。）

两个堆栈在UIViewAnimationState方法调用之前是相同的。来自异常处理程序的版本显示的是C ++错位名称，而不是崩溃日志中显示的常规名称。

（据我所知）_sigtramp是系统调用信号处理程序的方法，也是Signal Trampoline的缩写。超出此范围的堆栈条目可能是您的信号处理程序代码。

Answer 2

回答我自己的问题，几个星期，因为我没有相关的答案，大多数是猜测，我希望我有更准确的答案，但我想我的问题不清楚：

1. 差异来自日志的起源，一个sighandler vs CrashReporter服务，这些服务在不同时间发生，然后堆栈跟踪略有不同。
2. SIGBUS来自UIKit，但是从我的代码发起的回调中发生回调的可能性很大。当你无法重现这个问题时，这些堆栈跟踪很难调试，因为它基本上会告诉你＆＃34;我因为<而在某处崩溃 strong>一个动画＆＃34; ，其中一个......我仍然没有精确地想到。可能在任何地方，也可能是Apple iOS的错误。
3. 堆栈中的第一个地址只是 dead-end ，其中任何SIGBUS堆栈跟踪在调用释放的对象时结束。它们在编辑（版本）之间有所不同，但在任何设备上都是相同的，这就是为什么它们不能被象征化的原因。 （我希望对此有一个技术性的解释，而不是我的猜测）
4. ＆安培;我想我已经解决了这个错误，因为它更具刺激性。关于在某些情况下取消动画，例如取消分配一些观点......

希望能有所帮助。

Answer 3

您应该尝试NSZombie，以获取有关您已发布的对象的信息。当您获得EXC_BAD_ACCESS时，这是一个非常有用的工具。

要激活NSZombie，请执行以下操作：

1. 获取可执行文件的信息。
2. 转到参数选项卡。
3. 在“要在环境中设置的变量：”部分添加：

名称：NSZombieEnabled 价值：是

然后像往常一样运行您的应用程序，当它崩溃时，它应该告诉您哪个已解除分配的对象收到了该消息。

Answer 4

1。我不是百分百肯定，但我认为差异是由于应用程序的运行方式。在第二个日志中，看起来您正在调试模式下通过XCode运行应用程序，已发送sigtramp信号以指示EXC_BAD_ACCESS错误。

2。您的代码 - 错误可能来自UIKit库，但这是您使用时出现问题的结果。

3. 这是NSZombieEnabled让您的生活更轻松的地方！如果使用NSZombieEnabled标志设置运行应用程序，XCode将保留“zombie”对象来代替解除分配的对象。当一个僵尸对象被发送一条消息时，该进程将捕获该错误，并让您确切地知道该消息发送了什么对象。

如果你正在使用XCode 4，请按照以下说明启用NSZombieEnabled ......

How do I set up NSZombieEnabled in Xcode 4?

对于旧版本，请按照以下说明操作...

http://www.cocoadev.com/index.pl?NSZombieEnabled

4. 在动画完成之前，您的动画委托确实已经解除分配。