2

我最近在我的应用程序中启用了 BugSense来尝试帮助收集崩溃报告。我看到很多看起来像是在我的应用程序启动后立即发生的崩溃（我无法在我自己的任何设备上复制）。问题是我从 BugSense 获得的堆栈跟踪使它看起来我的应用程序实际上没有做任何导致崩溃的事情。我所看到的只是在跟踪中启动 AppDelegate 的第一个主要调用，然后是一堆不能很好地表示符号的库。

我意识到这可能没有足够的信息来弄清楚我的崩溃，但也许我可以在正确的方向上获得帮助。我无法在我自己的设备（以及其他几个人的设备）上进行复制，并且来自 BugSense 的堆栈跟踪来自已发布的应用程序。

这是 BugSense 给我的堆栈跟踪。

libsystem_kernel.dylib              0x3089232c __pthread_kill   70444
libsystem_c.dylib                   0x37d2cfeb abort   290795
libc  abi.dylib                     0x3078ef6b abort_message   28523
libc  abi.dylib                     0x3078c34d _ZL17default_terminatev   17229
libobjc.A.dylib                     0x37d7d2e3 _objc_terminate   37603
libc  abi.dylib                     0x3078c3c5 _ZL19safe_handler_callerPFvvE   17349
libc  abi.dylib                     0x3078c451 _ZdlPv   17489
libc  abi.dylib                     0x3078d825 __cxa_current_exception_type   22565
libobjc.A.dylib                     0x37d7d235 objc_exception_rethrow   37429
CoreFoundation                      0x38187545 CFRunLoopRunSpecific   62789
CoreFoundation                      0x381873a5 CFRunLoopRunInMode   62373
GraphicsServices                    0x37f5efcd GSEventRunModal   16333
UIKit                               0x31d07743 UIApplicationMain   202563
AppNameHD                           0x000039af 0x1000   10671

我正在使用来自Atos 的指令，它无法从归档应用程序的 dSYM 中获取符号来进行符号化。它适用于其他堆栈跟踪，在这些跟踪中我实际上看到了导致问题的一些代码，但并没有真正为我提供上述跟踪的任何信息。

4

2 回答 2

1

那些象征性的就好了。他们是什么被破坏了。它可能不会有太大帮助，但你可以解开它们：

% c++filt -n _ZdlPv
operator delete(void*)

我认为您不会从看门狗计时器中获得异常，但在启动时崩溃让我想知道这一点，以及崩溃日志是否包含 BADF00D。

于 2011-12-01T21:03:21.453 回答
1

该崩溃报告不会有太大帮助，您需要最后一个异常回溯来查看代码的哪些部分导致了崩溃。正如您在堆栈跟踪中看到的，异常被重新抛出，所以发生在另一个运行循环中。

更新版本的 PLCrashReporter（BugSense 崩溃报告也基于该版本）提供了这一点。http://code.google.com/p/plcrashreporter/

旁注：服务HockeyApp.net在其开源 SDK ( QuincyKit.net ) 中使用最新版本的 PLCrashReporter，在服务器上提供最后的异常回溯和符号化。（我是两者的成员）

于 2011-12-02T22:08:03.390 回答