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

时间:2017-06-02 19:59:45

标签: ios iphone swift debugging crash

当我在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

当然,我无法理解崩溃报告以及问题发生的位置。我知道我需要象征报告,有人能指出我如何象征的正确方向吗?

1 个答案:

答案 0 :(得分:0)

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

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

因此,如果您没有针对该特定应用构建的符号,则无法通过手动操作来获取符号。

如果您没有更改代码或构建设置,您可以尝试通过终端手动设置特定于应用程序的帧。为此,请按照以下步骤操作:

  1. 创建新版本(确保使用相同的构建配置!)。
  2. 然后您需要崩溃报告中的应用二进制文件中的加载地址(它是Binary Images下面提到您的应用的第一个内存地址。)
  3. 您还需要该二进制图像的CPU架构,例如: arm64,或armv7armv7s(如果已为设备完成构建)。在您的情况下,看起来构建属于arm64,因为显示的数据显示64位地址。
  4. 现在使用您想要符号化的内存地址列表调用atos(示例使用第1帧和第2帧的内存地址):

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

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