http://blog.csdn.net/xyxjn/article/details/43310061

http://blog.csdn.net/smking/article/details/9342899

1. 最近在解析umeng錯誤分析日誌上有了重大突破！  
2.   很顯然，我們的應用免不了crash，各種各樣的crash，不過大部分在提交至appstore前經過嚴格的“消毒”後，所剩無幾了。but（這個詞..）漏網之魚總是有的嘛（貌似很多..囧）。好吧，看下文：  
3.   首先看一些這些線上app crash 資訊：  
4. * Application received signal SIGSEGV  
5. * Application received signal SIGBUS  
6. * -[__NSArrayM objectAtIndex:]: index 4294967295 beyond bounds for empty array  
7. * -[JKArray objectAtIndex:]: index (0) beyond bounds (0)  
8. SIGSEGV和SIGBUS一般是因為訪問已被釋放的記憶體或者呼叫不存在的方法導致的，餘下兩個就是陣列越界的問題了 這些你都知道的，然後來看看具體的log資訊：  
9. Application received signal SIGSEGV  
10. Application received signal SIGSEGV  
11. (null)  
12. (  
13. 0   CoreFoundation                      0x32f1c3ff  + 186
14. 1   libobjc.A.dylib0x3ac17963 objc_exception_throw + 30
15. 2   CoreFoundation                      0x32f1c307  + 106
16. 3   appname                            0x14e1e1 appname + 1364449
17. 4   libsystem_c
    .dylib0x3b08bd33 _sigtramp + 34
18. 5   appname                            0x97525 appname + 615717
19. 6   CoreFoundation                      0x32e6d349 _CFXNotificationPost + 1420
20. 7   Foundation                          0x337879cd  + 168
21. 8   Foundation                          0x337876c1  + 136
22. 9   appname                            0x96f2f appname + 614191
23. 10  Foundation                          0x33858915  + 16
24. 11  Foundation                          0x33798769  + 200
25. 12  Foundation                          0x33798685  + 60
26. 13  CFNetwork                           0x32bf964f  + 26
27. 14  CFNetwork                           0x32bf8d33  + 54
28. 15  CFNetwork                           0x32c21013  + 18
29. 16  CoreFoundation                      0x32e62acd CFArrayApplyFunction + 176
30. 17  CFNetwork                           0x32c21473  + 74
31. 18  CFNetwork                           0x32b85461  + 188
32. 19  CoreFoundation                      0x32ef18f7  + 14
33. 20  CoreFoundation                      0x32ef115d  + 212
34. 21  CoreFoundation                      0x32eeff2f  + 646
35. 22  CoreFoundation                      0x32e6323d CFRunLoopRunSpecific + 356
36. 23  CoreFoundation                      0x32e630c9 CFRunLoopRunInMode + 104
37. 24  GraphicsServices                    0x36a4233b GSEventRunModal + 74
38. 25  UIKit                               0x34d7f2b9 UIApplicationMain + 1120
39. 26  appname                            0xf3df appname + 58335
40. 27  appname                            0x3578 appname + 9592
41. )  
42. dSYM UUID: 365EF56E-D598-

    相關推薦

    友盟抓取crash Log- 解析IOS崩潰日誌

    http://blog.csdn.net/xyxjn/article/details/43310061 http://blog.csdn.net/smking/article/details/9342899 最近在解析ume

    解析IOS崩潰日誌(crash Log)

    http://lieyunye.github.io/blog/2013/09/10/how-to-analyse-ios-crash-log/ http://blog.csdn.net/smking/article/details/9342899 最近在解析umeng錯

    Adplus 抓取Crash Dump

    mage win8 xxx ges adp 出現 ima flow window 本實例在win8.1 安裝window kits https://developer.microsoft.com/en-us/windows/hardware/windows-driver

    Android程序crash log解析

    Android程序crash會導致比較嚴重的問題， 輕則程序相關功能無法使用， 重則導致系統crash。 抓取對應的log和tombstone，會發現crash時列印的是一串地址棧，而不是對應的函式呼叫棧。 要解決問題，首要問題是把地址棧解析為對應的函式呼叫棧。   1.

    手機軟體測試如何使用adb命令抓取手機Log

    一般使用adb命令抓取手機的Log都是AP側的log，手機測試業內人士應該瞭解。 主要是 4中常見的log 1、radio log 2、main log 3、event log 4、kernel log 下面我們一一來介紹 1、radio log—— 通話、語音方面的lo

    crash log 解析方法

    1.  使用 dwarfdump 命令 ，需要首先進入 dSYM所在目錄 tans-Mac-mini:4.3-4.6Crash tangaowen$ dwarfdump --lookup 0x00097a87   --arch armv7 XXX.app.dSYM 2.

    [FAQ03891] 如何在User版本開啟串列埠(Uart),抓取上層Log,開啟輸入控制檯

    FAQ Content [Description] 如何在User版本開啟串列埠(Uart)，開啟輸入控制檯，抓取上層Log   [Keyword] User Uart Log Logcat 輸入 控制檯 串列埠   [Solution] (1) 如何在User版本中使用串

    Android抓取各種log的方法

    在分析app 時，我們通常需要分析app 的java heap 資料，如分析java 的memory leak, 追查heap 中相關變數情況等。 在android 中抓取app 的hprof 操作方式有下面幾種: 第一種方式: 使用am 命令    adb shell am dumpheap {Proces

    高通平臺如何offline 抓取systrace log

    Most kernel modules have tracing configuration, customer can switch on/off tracing event accordingly. For example, if you only care about bus vote, followi

    【資料抓取】HTML解析

    背景 通過模擬登陸，我獲取了相應網頁資訊，接下來要做的就是解析html，從裡面篩選出自己需要的內容 這個流程很清晰，獲取資料-篩選資料-儲存資料-顯示資料 功能說明 對htm

    iOS崩潰日誌解析指令碼

    在淺談iOS日誌收集系統中介紹瞭如何收集iOS崩潰日誌與如何解析iOS崩潰日誌，主要用到了兩個工具： plcrashutil：將plcrash檔案轉換成蘋果標準崩潰格式 symbolicatecra

    遭遇Crash檔案戰：教你如何搞定iOS崩潰日誌

    請叫我背景 最近在提交應用到App Store的時候，竟然被拒了兩次。那時候心裡的想法是，尼瑪完蛋了，要被老闆開除了，我是不是要失業了。於是乎那兩週幾乎毛腦子都是為什麼Apple你這麼狠心，我們明明相愛了那麼多年，你竟然就這樣拋棄了我。我不想活了，不要攔著我，我要分分

    iOS崩潰日誌 如何看

    ffd 通過 1.0 san version sig cps fff pre 轉載至搜狗測試 日誌主要分為六個部分：進程信息、基本信息、異常信息、線程回溯、線程狀態和二進制映像。 我們在進行iPhone應用測試時必然會在“隱私”中找到不少應用的崩潰日誌，但是不會閱讀對於

    iOS 崩潰日誌分析（個人總結，最實用）

    要分析奔潰日誌需要三個檔案：crash日誌，symbolicatecrash分析工具，.dSYM符號集 0. 在桌面建立一個crash資料夾 1. 需要Xcode自帶的崩潰分析工具symbolicatecrash，這個檔案的位置參考：/Applications/Xcode.

    iOS 崩潰日誌 Backtrace的符號化

    iOS的崩潰日誌配合dsym檔案可以找到崩潰時的backtrace,這是解決崩潰的最重要的資訊. 如果是在同一臺mac上打包, 匯入crash log時候會自動將backtrace符號化,可以看到方法名, 檔名和行號 但是,有時候發版的包不是在你的mac上打包的,xcode

    iOS 崩潰日誌 收集與傳送伺服器

    iOS開發中我們會遇到程式丟擲異常退出的情況，如果是在除錯的過程中，異常的資訊是一目瞭然，我們可以很快的定位異常的位置並解決問題。那麼當應用已經打包，iPhone裝置通過ipa的包

    iOS 崩潰日誌收集及分析

    最近幾天，專案中在增加推送功能，選用的極光推送SDK，相信大家也都用過，官方文件的整合步驟很詳細，整合也很容易。但是這跟今天的主題有什麼關係呢？？？ 黑人問號？？？別急，下面就來說說我今天的遭遇。坑~~~ 話說，由於iOS10之後，蘋果對推送進行了重大更新，主要是新增了 U

    用Crashlytics收集ios崩潰日誌

    Crashlytics主要解決2個問題： 1、crash log的收集 2、crash log符號化 初步用了一下，感覺還不錯。先到crashlytics申請一個賬號，然後過幾天會收到邀請碼。之後用邀請碼登陸，再按步驟操作即可 在將Crashlytics整合進app的過程中

    如何看iOS崩潰日誌

    連接 stop 全部 產生 guid 數據 繼續 進程 返回 重點：Triggered by Thread這句話後邊的線程號，快速定位問題出現在那個線程，是否是你的鍋；Triggered by Thread所指的線程表示導致異常、崩潰的線程 下邊內容轉自簡書 簡介 當一個

    IOS崩潰Crash分析（MTA騰訊雲分析，友盟）

    公司做IOS的走了，東西就丟給了我這個從來沒有做過IOS的。最近為了捕獲BUG，集成了MTA平臺的BUG收集。問題就來了，對於我這種，雖然沒有學過OC，但是寫寫程式碼還是可以的，xCode中除錯下BUG也行，但是碰到這種Crash的，還不帶崩潰路徑的，完全