如何理解在iPhone

崩潰報告的iOS測試當我測試我的iPhone我的iOS應用程序，它會立即崩潰。從Xcode中，窗口 - >設備 - > iPhone，我能夠得到以下崩潰報告：如何理解在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

當然，我是無法理解的崩潰報告和發生問題的。我知道我需要象徵這份報告，有人能指出我如何象徵性地指出正確的方向嗎？

來源

2017-06-02 JK140

的Xcode需要從觸發了symbolicates的崩潰報告在Mac上構建的確切構建符號（的dSYM）。每個版本都有一個唯一的UUID（每個CPU架構一個）標識，該UUID嵌入到應用程序二進制文件和符號文件中。崩潰報告在每個加載的二進制文件的Binary Images部分中包含該UUID。符號化過程使用Spotlight來查找正確的符號，如果找不到它，則無法表示相應堆棧幀的內存地址。

每當您更改項目中的代碼（或更改構建設置）並觸發新構建時，UUID也會發生變化，並且新符號文件不能用於舊構建的崩潰報告。

所以，如果你不具備可用的特定應用構建的象徵，它是不可能得到的符號，無需人工努力。

如果您沒有更改代碼或構建設置，你可以嘗試通過終端手動symbolicate應用程序的特定幀。要做到這一點，請按照下列步驟操作：

創建新構建（確保使用相同的構建配置！）。
然後，你需要從崩潰報告（這是在下面Binary Images行，其中提到您的應用程序的第一存儲器地址）的應用程序二進制加載地址。
您還需要該二進制圖像的CPU架構，例如arm64或armv7或armv7s（如果構建是爲設備完成的）。在你的情況下，它看起來像構建爲arm64所示的數據顯示64位地址。

現在叫atos與要symbolicate內存地址的列表（例如使用1幀的存儲器地址和2）：

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

現在你應該得到的2提供存儲2個符號地址。如果你很幸運（當使用新的dSYM），它們是有幫助的。

來源

2017-06-02 20:46:34 Kerni

如何理解在iPhone

回答

相關問題