標籤:
今天在友盟的錯誤分析裡面找到了一個這樣的錯誤:
Application received signal SIGSEGV (null) ( 0 CoreFoundation 0x2ef6dfeb + 154 1 libobjc.A.dylib 0x3971cccf objc_exception_throw + 38 2 CoreFoundation 0x2ef6df15 + 0 3 appname 0xcc979 appname + 821625 4 libsystem_platform.dylib 0x39d43f8b _sigtramp + 34 5 UIKit 0x31842261 + 44 6 UIKit 0x31842261 + 44 7 UIKit 0x31842261 + 44 8 UIKit 0x318ab1d9 + 256 9 UIKit 0x3182d97f + 142 10 UIKit 0x318aaefd + 128 11 UIKit 0x31808115 + 312 12 UIKit 0x31808407 + 106 13 UIKit 0x31884c37 + 46 14 Foundation 0x2f94d163 __NSFireDelayedPerform + 414 15 CoreFoundation 0x2ef391b7 + 14 16 CoreFoundation 0x2ef38dcf + 782 17 CoreFoundation 0x2ef3716b + 1210 18 CoreFoundation 0x2eea1f0f CFRunLoopRunSpecific + 522 19 CoreFoundation 0x2eea1cf3 CFRunLoopRunInMode + 106 20 GraphicsServices 0x33da6663 GSEventRunModal + 138 21 UIKit 0x317ed16d UIApplicationMain + 1136 22 veryWallen 0x85613 veryWallen + 529939 23 libdyld.dylib 0x39c29ab7 + 2 ) dSYM UUID: 76634C55-B73F-303D-BA7C-511D5B84D45A CPU Type: armv7 Slide Address: 0x00004000 Binary Image: veryWallen Base Address: 0x0008b000
Application received signal SIGSEGV (null)
SIGSEGV和SIGBUS一般是因為訪問已被釋放的記憶體或者調用不存在的方法導致的,那麼上面所說的崩潰資訊基本就能定性為記憶體被釋放啦?問題是在哪裡崩潰的呢,完全不知道啊,所以只能往裡找了。
使用showinfinder進入
/Users/username(電腦名)/Library/Developer/Xcode/Archives/這個檔案夾,你會看到你打包時產生的xcarchive檔案,當然你得用Archives來打包。
然後來尋找正確的包吧,也就是崩潰程式的這個包的dSYM UUID必須和上面崩潰資訊的一樣。
開啟終端,輸入cd 然後拖進
xcarchive
檔案吧,記得加上/dSYMs然後斷行符號,這樣你就進入了/dSYMs的目錄了,再輸入
dwarfdump --uuid appname.app.dSYM
命令,可別腦子壞掉的也輸appname就成,然後你就能看到
armv7 和 armv7s的 兩個UUID了,對比下就能知道是否是這個包了,不是就繼續試直到找到位置
當你找到是哪個包了在來看下一步。。。
看看這句
3 appname 0xcc979 appname + 821625
這就是崩潰時調用的地方,在終端繼續輸入
dwarfdump --arch=armv7 --lookup 0xcc979 對應的包的路徑/dSYMs/appname.app.dSYM/Contents/Resources/DWARF/appname
就會得出結果,如果你前面沒有敲錯,那麼你應該能看到不一樣的Log資訊,不是麼,
看一下結果:發現有AT_name、Line table dir :、Line table file,沒錯,你能找到了出錯的檔案,是哪一行。。。
於是剩下的就靠你自己判斷了。。。
今天到此為止!!!
還不明白看這個,我也是在緊跟前人的腳步
http://lieyunye.github.io/blog/2013/09/10/how-to-analyse-ios-crash-log/
[轉]UMeng的錯誤分析