但隨之而來的問題是，我們收到的程式崩潰除錯資訊多半是組合語言一樣的堆疊**，同時這些資訊並不是在我們debug的時候產生，所以看到這一串crash log的天書，常常無可奈何。xcode很好的解決了這一問題，它所提供的orgainzer分析器加上symbolicatecrash，可以分析二進位制檔案以及源**和crashlog之間的連線，直接找出源程式中出錯的**行。方法網上到處是，本文不討論。
但是如果使用symbolicatecrash無法定位到出錯的**行的話，怎麼整呢？有乙個辦法，如下：
首先檢視crash log中的崩潰執行緒，假如是這樣的：
在控制台使用dwarfdump命令，解析出記憶體位址，如：
輸出資訊如下：
直接定位到**的出錯行，cool！
Xcode分析CrashLog的方法
m 搞iphone開發就要不停地發版本，隨之而來的就是各種版本的crash log。如果不能好好地管理，那麼開發人員很快就會在crash log和版本的海洋裡迷失方向。使用起來很簡單。分三步即可。3 用dwarfdump檢查dsym檔案是否是上面的uuid。命令列格式 如果三者的uuid都是一致的，...
Android程序crash log解析
android程序crash會導致比較嚴重的問題，輕則程序相關功能無法使用，重則導致系統crash。抓取對應的log和tombstone，會發現crash時列印的是一串位址棧，而不是對應的函式呼叫棧。要解決問題，首要問題是把位址棧解析為對應的函式呼叫棧。1.addr2line cd prebuilt...
Xcode一些Analyze分析的錯誤
1.錯誤 user facing text should use localized string macro 給label賦值的時候，提示 面向使用者的文字應該使用本地化的字串巨集 此為 中配置了本地化,面向使用者的應該用字串巨集,而我們直接賦值為漢字.解決方法 因為copy 通常會返回不可變的副...