ios - 如何理解 iPhone 上的崩溃报告 iOS 测试

Question

当我在 iPhone 上测试 iOS 应用程序时，它立即崩溃。从 Xcode，Window->Devices->iPhone，我可以获得以下崩溃报告:

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x0000000100a69dc0
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [0]
Triggered by Thread:  3

Filtered syslog:
None found


Thread 3 name:  Dispatch queue: NSOperationQueue 0x170228680 :: 
NSOperation 0x17005ba80 (QOS: DEFAULT)
Thread 3 Crashed:
0   libswiftCore.dylib              0x0000000100a69dc0 0x10090c000 +     1433024
1   appName_iOS                     0x00000001000a6510 0x10000c000 +     632080
2   appName_iOS                     0x0000000100019b38 0x10000c000 +     56120
3   CFNetwork                       0x0000000192c101fc __75- [__NSURLSessionLocal taskForClass:request:uploadFile:bodyData:completion:]_block_invoke + 32
4   CFNetwork                       0x0000000192c27ef8 __49-[__NSCFLocalSessionTask _task_onqueue_didFinish]_block_invoke + 148
5   Foundation                      0x00000001930d5804 __ NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16
6   Foundation                      0x000000019301a760 -[NSBlockOperation main] + 96
7   Foundation                      0x000000019300ab18 -[__NSOperationInternal _start:] + 612
8   Foundation                      0x00000001930d7ba0 __NSOQSchedule_f + 228
9   libdispatch.dylib               0x00000001914be9a0 _dispatch_client_callout + 16
10  libdispatch.dylib               0x00000001914ccad4 _dispatch_queue_serial_drain + 928
11  libdispatch.dylib               0x00000001914c22cc _dispatch_queue_invoke + 884
12  libdispatch.dylib               0x00000001914cea50 _dispatch_root_queue_drain + 540
13  libdispatch.dylib               0x00000001914ce7d0 _dispatch_worker_thread3 + 124
14  libsystem_pthread.dylib         0x00000001916c71d0 pthread_wqthread + 1096
15  libsystem_pthread.dylib         0x00000001916c6d7c start_wqthread + 4

Thread 3 crashed with ARM Thread State (64-bit):
x0: 0x0000000100f00380   x1: 0x00000001702e5a80   x2: 0x0000000000000008   x3: 0x00000001916472c0
x4: 0x0000000000000038   x5: 0x0000000000000010   x6: 0x0000000000000000   x7: 0x0000000000000d60
x8: 0x00000001702e5c00   x9: 0x00000001702e5c00  x10: 0x0000000000000001  x11: 0xbaddc0dedeadbead
x12: 0x0000010000000100  x13: 0x0000000000000028  x14: 0x0000000000000001  x15: 0x0000000000000881
x16: 0x0000000191637a1c  x17: 0x0000000000000000  x18: 0x0000000000000000  x19: 0x0000000174051cd0
x20: 0x0000000000000000  x21: 0x00000001a0eeac53  x22: 0x0000000000000000  x23: 0x0000000174051cd0
x24: 0x0000000000000000  x25: 0x00000000000000d8  x26: 0x00000001b737b000  x27: 0x000000016e0570e0
x28: 0x0000000000000000   fp: 0x000000016e056700   lr: 0x0000000100a69dc0
sp: 0x000000016e0566f0   pc: 0x0000000100a69dc0 cpsr: 0x20000000

当然，我无法理解崩溃报告以及问题发生的位置。我知道我需要对报告进行符号化，有人可以为我指出如何符号化的正确方向吗？

Answer 1

Xcode 需要来自触发 Mac 上构建(表示崩溃报告)的确切构建的符号 (dSYM)。每个构建都使用唯一的 UUID(每个 CPU 架构一个)进行标识，该 UUID 嵌入在应用程序二进制文件和符号文件中。崩溃报告在每个加载的二进制文件的 Binary Images 部分中包含该 UUID。符号化过程使用Spotlight来查找正确的符号，如果找不到，则无法符号化相应堆栈帧的内存地址。

每当您更改项目中的代码(或更改build设置)并触发新构建时，UUID 也会更改，并且新符号文件不能用于旧版本的崩溃报告。

因此，如果您没有可用的特定应用程序版本的符号，则无需手动操作就无法获取符号。

如果您没有更改代码或build设置，您可以尝试通过终端手动符号化应用程序特定的框架。为此，请按照下列步骤操作:

1. 创建新的构建(确保使用相同的构建配置!)。
2. 然后，您需要崩溃报告中应用二进制文件的加载地址(这是Binary Images 下面提到您的应用的行中的第一个内存地址)。
3. 您还需要该二进制图像的 CPU 架构，例如arm64、armv7 或 armv7s(如果是为设备构建的)。在您的情况下，看起来构建是针对 arm64 的，因为显示的数据显示 64 位地址。

现在使用您想要符号化的内存地址列表调用atos(示例使用帧 1 和 2 的内存地址):

atos -arch arm64 -l TheLoadAddressOfTheBinary -o YourDsymPackage.dSYM/Contents/Resources/DWARF/YourDsymFile  0x00000001000a6510 0x0000000100019b38

您现在应该获得 2 个提供的内存地址的 2 个符号。如果你幸运的话(当使用新的 dSYM 时)，它们会很有帮助。