iOS坠机报告-如何找到坠毁地点

Question

最后，我上传了应用程序到应用商店。我使用的也是狂暴的分析，很少有错误被捕捉到。

我试图附加dSYM文件以提高它的可读性，但是我不确定这类日志的哪一部分更改为人类可读的文本。

这里还有一件事:我没有看到任何指向我的类文件的行(实现)。

所以我的问题是--我怎样才能从这样的报告中获得更多的信息？--这款应用真的在用户设备上崩溃了吗？或者这样的错误对于一个用户来说是不可见的？-是否可能应用程序没有崩溃，但可能是用户杀死了它的进程？

谢谢

这是坠机报告

Hardware Model:      iPhone3,3
Process:         my-app [560]
Path:            /var/mobile/Applications/3539397F-14A1-4802-A388-1D5070404D98/my id
Identifier:      /my id
Version:         1.3
Code Type:       ARM
Parent Process:  launchd [1]

Exception Type:  SIGSEGV
Exception Codes: SEGV_ACCERR at 0x70000008
Crashed Thread:  0

Thread 0 Crashed:
0   libobjc.A.dylib                     0x34dde5b0 +[Protocol load] + 663
1   UIKit                               0x3471b4a7 0x34699000 + 533671
2   UIKit                               0x346b1abb 0x34699000 + 101051
3   UIKit                               0x347268d7 0x34699000 + 579799
4   QuartzCore                          0x34cdabd9 -[CALayer dealloc] + 1244
5   libdispatch.dylib                   0x3793d4b7 0x3793c000 + 5303
6   libdispatch.dylib                   0x3793edcb -[OS_object release] + 274
7   CoreFoundation                      0x3826af3b +[__NSCFLocale         automaticallyNotifiesObserversForKey:] + 12398
8   CoreFoundation                      0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
9   CoreFoundation                      0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
10  GraphicsServices                    0x3887a2eb 0x38875000 + 21227
11  UIKit                               0x346f0301 0x34699000 + 357121
12  my-app                              0x0012987b -[ASIHTTPRequest setSynchronous:] + 86

Thread 1:
0   libsystem_kernel.dylib              0x3568c648 0x3568b000 + 5704
1   libdispatch.dylib                   0x3793fdf8 -[OS_object _dispose] + 579

Thread 2:
0   libsystem_kernel.dylib              0x3568beb4 0x3568b000 + 3764
1   CoreFoundation                      0x3826c045 +[__NSCFLocale     automaticallyNotifiesObserversForKey:] + 16760
2   CoreFoundation                      0x3826ada3 +[__NSCFLocale  automaticallyNotifiesObserversForKey:] + 11990
3   CoreFoundation                      0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4   CoreFoundation                      0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5   WebCore                             0x3689ca75 +[WebScriptObject initialize] + 608
6   libsystem_c.dylib                   0x364f5311 0x364e4000 + 70417

Thread 3:
0   libsystem_kernel.dylib              0x3568beb4 0x3568b000 + 3764
1   CoreFoundation                      0x3826c045 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 16760
2   CoreFoundation                      0x3826ada3 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 11990
3   CoreFoundation                      0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4   CoreFoundation                      0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5   Foundation                          0x3264cbcd +[NSURLConnection _resourceLoadLoop:] + 308
6   Foundation                          0x326d067d -[NSThread description] + 1096
7   libsystem_c.dylib                   0x364f5311 0x364e4000 + 70417

Thread 4:
0   libsystem_kernel.dylib              0x3568beb4 0x3568b000 + 3764
1   CoreFoundation                      0x3826c045 +[__NSCFLocale  automaticallyNotifiesObserversForKey:] + 16760
2   CoreFoundation                      0x3826ada3 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 11990
3   CoreFoundation                      0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4   CoreFoundation                      0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5   my-app                           0x001275eb +[ASIHTTPRequest runRequests] + 170
6   Foundation                          0x326d067d -[NSThread description] + 1096
7   libsystem_c.dylib                   0x364f5311 0x364e4000 + 70417

Thread 5:
0   libsystem_kernel.dylib              0x3569c594 0x3568b000 + 71060
1   libsystem_c.dylib                   0x364f5311 0x364e4000 + 70417

Thread 6:
0   libsystem_kernel.dylib              0x3568beb4 0x3568b000 + 3764
1   CoreFoundation                      0x3826c045 +[__NSCFLocale   automaticallyNotifiesObserversForKey:] + 16760
2   CoreFoundation                      0x3826ada3 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 11990
3   CoreFoundation                      0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4   CoreFoundation                      0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5   Foundation                          0x3262378f +[NSNotification allocWithZone:] + 334
6   Foundation                          0x326c705d +[NSPropertyListSerialization propertyListWithStream:options:format:error:] + 9132
7   my-app                              0x0013a9ad +[TFURLConnectionOperation _runNetworkThread:] + 140
8   Foundation                          0x326d067d -[NSThread description] + 1096
9   libsystem_c.dylib                   0x364f5311 0x364e4000 + 70417

Thread 7:
0   libsystem_kernel.dylib              0x3569cd98 0x3568b000 + 73112
1   libsystem_c.dylib                   0x364eaa16 0x364e4000 + 27158

Thread 8:
0   libsystem_kernel.dylib              0x3569cd98 0x3568b000 + 73112
1   libsystem_c.dylib                   0x364eaa16 0x364e4000 + 27158

Thread 0 crashed with ARM Thread State:
r0: 0x1fc42250     r1: 0x34b1bee8     r2: 0x2fdf0d60     r3: 0x348a80d5 
r4: 0x70000000     r5: 0x1fc42250     r6: 0x1fc42360     r7: 0x2fdf0e3c 
r8: 0x1ed3c720     r9: 0x0d2c6fba    r10: 0x1fc1b290    r11: 0x00000001 
ip: 0x3b9a7d64     sp: 0x2fdf0db4     lr: 0x3471b84b     pc: 0x34dde5b0 
cpsr: 0x20000030 

Answer 1

关于你的问题：

问题1:如何从这样的报告中获得更多的信息？

答案：

1. 信号为SIGSEGV，这基本上意味着分割故障。造成这种崩溃的原因有几个，例如，过度释放的对象、未初始化的指针或直接写入内存的代码。
2. 崩溃线程在堆栈跟踪中显示一个dealloc调用。这意味着，当一个对象被解除分配时，造成了崩溃。
3. 许多后台线程正在使用ASIHTTPRequest运行网络操作，堆栈跟踪中有类似的调用。
4. 有很多提到automaticallyNotifiesObserversForKey的地方，这暗示了关键值的观察是相关的.也许有一个注册到密钥的观察者，而观察者已经被释放了。这甚至更棘手，因为通知是从后台线程触发的！例如，在后台建立网络，并在主线程上使用对象进行观察。如果不确保主线程上的对象存在足够长的时间，那么在这些场景中很容易得到这样的崩溃。
5. 非常奇怪的是，多个后台线程对于单个堆栈帧具有几乎相同的堆栈跟踪和甚至相同的内存地址。

假设：，如果您不能重现这个问题，您可能找不到原因。我怀疑它与ASIHTTPRequest和它的内部键值编码处理或您自己的使用有某种关系。因此，我将替换该库，例如用AFNetworking或使用iOS提供的普通网络堆栈。此外，如果您正在使用键值编码，请检查有关多线程安全性的代码.

问题2:是真的，应用程序真的在用户设备上崩溃了吗？

是的，只有在应用程序崩溃时才能得到这些报告。

问题3:或者这样的错误对于用户来说是不可见的？

不，SIGSEGV是你的应用程序的真正崩溃。如果您捕捉到代码中的异常，并且仍然生成一个报告并将其发送过来，Invisible就会出现。但据我所知，Flurry并没有提供这个特性，您显然没有实现它，而且崩溃也不是由异常引起的。这是不可能的。

问题4:是否有可能应用程序没有崩溃，但可能是用户杀死了它的进程？

如果应用程序被毁了，你就不会得到一份“狂风”的崩溃报告。死亡是由iOS触发的，进程中的崩溃报告库(这意味着每一个第三方崩溃报告服务)永远无法为其创建报告。

附加注意：异常断点(正如其他人建议的那样)对这种类型的崩溃没有帮助，因为它没有崩溃，因为发生了异常。

Answer 2

可以直接问在Fly--crashanalytics@flurry.com吗？我希望他们能更好地帮助你。

看看你所在的地方--你在那里做网络请求--我认为这在这个地方是有意义的。

为了进行更好的测试，我认为您需要找到iPhone3.3版本(我知道这是verizon 4)，并尝试在此设备上直接调试应用程序。