原文地址：http://www.acwind.net/blog/?p=1090

Bug是永遠(yuǎn)伴隨著程序員們的東西，各種各樣的情況造成程序crash掉也是家常便飯。Windows下的很多大型軟件在崩潰的時(shí)候，都會(huì)彈出提示框，詢(xún)問(wèn)用戶(hù)是否將crash的信息發(fā)送到軟件廠(chǎng)商，以供軟件開(kāi)發(fā)商debug。App store中的軟件也有這個(gè)功能，用戶(hù)在使用軟件的時(shí)候，如果程序崩潰，錯(cuò)誤信息會(huì)發(fā)送到Apple的服務(wù)器中，軟件的開(kāi)發(fā)者們可以很方便在后臺(tái)獲得自己程序的crash log，供自己調(diào)試。

但隨之而來(lái)的問(wèn)題是，我們收到的程序崩潰調(diào)試信息多半是匯編語(yǔ)言一樣的堆棧代碼，同時(shí)這些信息并不是在我們debug的時(shí)候產(chǎn)生，所以看到這一串crash log的天書(shū)，常常無(wú)可奈何。Xcode很好的解決了這一問(wèn)題，它所提供的Orgainzer分析器加上symbolicatecrash?，可以分析二進(jìn)制文件以及源代碼和crashlog之間的連接，直接找出源程序中出錯(cuò)的代碼行。方法網(wǎng)上到處是，本文不討論。

但是如果使用symbolicatecrash?無(wú)法定位到出錯(cuò)的代碼行的話(huà)，怎么整呢？有一個(gè)辦法，如下：

首先查看crash log中的崩潰線(xiàn)程，假如是這樣的：

Thread 0 Crashed:
0   libobjc.A.dylib                0x00003ec0 objc_msgSend + 24
1   MyApp               0x000036d2 0×1000 + 9938?

我們得到了用戶(hù)發(fā)生崩潰情況的內(nèi)存地址：0x000036d2?

然后回到我們應(yīng)用程序的build目錄，目錄下一定要包含MyApp.app 和MyApp.app.dSYM兩個(gè)文件。

在控制臺(tái)使用dwarfdump命令，解析出內(nèi)存地址，如： 

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

輸出信息如下：

直接定位到代碼的出錯(cuò)行，Cool！