iOS 应用程序崩溃，符号化日志不透明

Question

我相信我正在查看正确符号化的日志，但如果不是这样，请告诉我。这是我从 Apple 收到的由于启动时崩溃而被拒绝后的崩溃日志的摘录，我完全无法复制该日志。

我安装了一个名为 Crashlytics 的崩溃报告系统，该系统在应用审查期间没有收到任何崩溃报告，这让我相信崩溃发生在 AppDelegate 的 didFinishLaunchingWithOptions 初始化 Crashlytics 之前。也就是说，Crashlytics 仅在崩溃后重新打开应用程序时发送报告。因此，Apple 审阅者可能遇到了崩溃并且没有费心再次尝试，这可能是我没有 Crashlytics 报告的原因。

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread:  0

Last Exception Backtrace:
(0x181f9a084 0x1929ec0e4 0x180819674 0x100091318 0x100084fe4 0x100084098 0x18671d158 0x18671ce68 0x1867d0ee8 0x1869d1da8 0x186791938 0x18671e88c 0x1867906f8 0x10006187c 0x18678e5d0 0x1869a4de8 0x1869a7568 0x1869a5c00 0x18a171640 0x181f52360 0x181f51468 0x181f4fa8c 0x181e7d664 0x18678798c 0x186782984 0x100061c28 0x19305aa08)

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib          0x0000000193172964 __kill + 8
1   Luff                            0x00000001001330dc 0x10005c000 + 880860
2   libsystem_platform.dylib        0x0000000193208958 _sigtramp + 64
3   libsystem_pthread.dylib         0x0000000193211224 pthread_kill + 108
4   libsystem_c.dylib               0x00000001930eab14 abort + 108
5   libc++abi.dylib                 0x00000001921d1414 abort_message + 112
6   libc++abi.dylib                 0x00000001921f0b88 default_terminate_handler() + 300
7   libobjc.A.dylib                 0x00000001929ec3bc _objc_terminate() + 124
8   libc++abi.dylib                 0x00000001921edbb0 std::__terminate(void (*)()) + 12
9   libc++abi.dylib                 0x00000001921ed738 __cxa_rethrow + 140
10  libobjc.A.dylib                 0x00000001929ec290 objc_exception_rethrow + 40
11  CoreFoundation                  0x0000000181e7d710 CFRunLoopRunSpecific + 568
12  UIKit                           0x0000000186787988 -[UIApplication _run] + 548
13  UIKit                           0x0000000186782980 UIApplicationMain + 1484
14  Luff                            0x0000000100061c24 0x10005c000 + 23588
15  libdyld.dylib                   0x000000019305aa04 start + 0

Answer 1

你所拥有的并不是完全象征性的。为了使其完全符号化，即在第 14 行和第 1 行使用函数名称以及最后一个异常回溯，您需要 dSYM 文件，该文件将在您构建应用程序时生成提交并放置在与您的应用程序包相同的文件夹中。如果您使用 Xcode 的存档功能，我相信 dSYM 包含在存档中。我说第 1 行和第 14 行是因为它们上面有您的应用名称 (Luff)。

您需要做的是将崩溃报告、dSYM 文件和应用程序文件（不是 IPA）放在同一个文件夹中（我不确定应用程序文件是否真的需要 Xcode 进行符号化，因此请确保它如果它不能仅与崩溃报告和 dSYM 一起使用，是否存在）。然后，将崩溃报告导入 Xcode 管理器并点击“Re-symbolicate”。

如果没有 dSYM，您现在拥有的上述内容是 100% 无用的，除非您能以某种方式将报告中的地址映射到符号（函数、方法）。

此外，崩溃线程的堆栈跟踪不在相关信息所在的位置。不过，根据经验，我可以告诉你一些关于堆栈跟踪的事情。第 14 行的符号很可能是您的 main() 函数。那里没什么特别的。

1 到 14 之间的行显示了一堆异常的重新抛出和捕获，也就是说，这不是导致崩溃的堆栈跟踪，而是被传递的异常的堆栈跟踪。既然你提到你有 Crashlytics，我敢打赌第 14 行就是这样。它说 Luff 而不是 Crashlytics，因为 Crashlytics 是嵌入到您的应用程序中的静态库。出于所有意图和目的，iOS 将其视为应用程序的另一部分。我说它是 Crashlytics 的原因是当你捕捉到崩溃时，导致崩溃的东西（异常、信号等）有时会被重新抛出，它最终会到达你自己的自定义崩溃报告代码。

相关信息在您上面的Last Exception Backtrace 地址中。但要阅读它，必须用 dSYM 文件对其进行符号化。

正如您所说，Crashlytics 不是实时的。用户需要重新打开应用程序。我知道这一切，因为我正在开发自己的名为 Crashional 的实时项目，前提是有互联网连接。

Answer 2

您未通过 Crashlytics 收到报告的一个可能原因是，审核者在首次启动您的应用时可能在设备上禁用了互联网。即使她再次打开它，它也不会将崩溃发送回 Crashlytics。