ios分析 Crash Log

From:http://wjl4926.blog.163.com/blog/static/97330204201272162313115/

當釋出到iPhone上的應用程式Crash之後，iPhone會自動生成一個Crash Log（*.crash），這個檔案包含了一些有用的調試資訊，但對于堆棧，它隻記錄的函數位址，而無法顯示函數名。函數名儲存在一個叫dSYM的二進制檔案中，即一個調試符号表檔案。要解析出Crash log中的函數名稱，必須要這個dSYM檔案和可執行程式（即那個*.app包）。而且這三者必須嚴格對應，也就是說他們包含的UUID号必須一樣。

可以用MAC自帶的dwarfdump程式來檢查UUID：

使用dwarfdump檢查app，看哪個app是上面那個UUID。指令行格式： dwarfdump --uuid YourApp.app/YourApp 用dwarfdump檢查dSYM檔案是否是上面的UUID。指令行格式： dwarfdump --uuid YourApp.app.dSYM

這兩個UUID必須一樣，而且必須跟Crash Log裡面的UUID一緻。打開Crash Log檔案，在”Binary Images：”段中，YourApp後面的尖括号内的字元串就是UUID了。  crash log uuid : armv7  <1dd5eb047491310f88cb7b1d7f61275c> /var/mobile/Applications/581404D9-FF06-455F-8251-846D41D18B40/

  有了這三樣東西，就可以用Xcode的Organizer來檢視包含了符号資訊的Crash log了，這個過程也稱為symbolication。方法是：

先将app和dYSM兩個檔案拷貝到使用者目錄下的任意子目錄中（我試過任意兩層目錄），然後在Organizer中選中“Device Logs”，接下來将Crash log檔案拖動到這個視窗中，Organizer将開始尋找對應的檔案，然後進行轉換，轉換後儲存在它自己的一個目錄下（在視窗中的log上右鍵點選選“Reveal Log inFinder”可以看到轉好的檔案）。

但随之而來的問題是，我們收到的程式崩潰調試資訊多半是彙編語言一樣的堆棧代碼，同時這些資訊并不是在我們debug的時候産生，是以看到這一串crash log的天書，常常無可奈何。Xcode很好的解決了這一問題，它所提供的Orgainzer分析器加上symbolicatecrash，可以分析二進制檔案以及源代碼和crashlog之間的連接配接，直接找出源程式中出錯的代碼行。方法網上到處是，本文不讨論。

但是如果使用symbolicatecrash無法定位到出錯的代碼行的話，怎麼整呢？有一個辦法，如下：

首先檢視crash log中的崩潰線程，假如是這樣的：

Thread 0 Crashed:

0   libobjc.A.dylib               0x00003ec0 objc_msgSend + 24

1   MyApp               0x000036d2 0×1000 + 9938

我們得到了使用者發生崩潰情況的記憶體位址：0x000036d2

然後回到我們應用程式的build目錄，目錄下一定要包含MyApp.app 和MyApp.app.dSYM兩個檔案。

在控制台使用dwarfdump指令，解析出記憶體位址，如： 

dwarfdump –lookup 0x000036d2 –arch armv6 MyApp.app.dSYM