objective-c - 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 管理器并单击“重新符号化”。

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

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

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

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

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