Xcode崩潰除錯

xcode還是比較好用的，搜尋方便，只有充分的摸索各個視窗能找到各種資訊。

可以在下面console臺輸入命令列檢視：

thread info ：可以檢視當前斷點執行緒的資訊，如果再加上乙個數字引數表示檢視某個執行緒號的資訊

thread backtrace：可以檢視呼叫棧

exec_bad_access的提示。如下圖，在斷點的導航面板建立了exception斷點全域性斷點，這樣只要遇到錯誤，debug程式就會自動定位到棧底的資訊，也就是你最先出錯的**的那一行

如上圖，第四個，增加函式斷點，輸入要斷的函式名 func***，這樣一來，在程式中所有的 func*** 方法被呼叫時都會觸發斷點。

崩潰時候的日誌

輸入lldb偵錯程式命令bt看棧資訊 （thread info、thread backtrace）

或者直接選中左側的棧資訊，複製貼上到文字，這個比較詳細（直接bt不會顯示出下文中加粗的部分）

#0  0x000000022947a0dc in __pthread_kill ()

#1  0x00000002294f79b0 in pthread_kill$variant$armv81 ()

#2  0x00000002293d3ea8 in abort ()

#3  0x00000002294cd780 in malloc_vreport ()

#4  0x00000002294cd938 in malloc_report ()

#5  0x00000002294c05e8 in free ()

#6  0x00000001057adaa8 in b2free(void*) at/users/mobile/downloads/clinet6/clinet/base/b2settings.cpp:33

#7  0x00000001057ac214 in b2blockallocator::~b2blockallocator() at/users/mobile/downloads/clinet6/clinet/base/b2blockallocator.cpp:88

#8  0x00000001057ac240 in b2blockallocator::~b2blockallocator() at/users/mobile/downloads/clinet6/clinet/base/b2blockallocator.cpp:82

而且兩個類的同名函式實現不一致。

上面可以看到是b2blockallocator::~b2blockallocator 這個符號本來需要呼叫的是unity的靜態庫中的函式，但是最終呼叫到了專案中自己實現的網路庫中的函式。最終在執行這個專案中這個函式的時出現了崩潰，因為free了乙個沒有分配過的記憶體。

因為ios是靜態庫，在鏈結是最終生成的可執行檔案中就會對符號進行決議。

但是如果是android平台，用的是動態鏈結，不會出現這個問題。

Redis崩潰除錯

redis的 質量一直被業內人士稱讚，在極高的業務壓力下也能有很好的穩定性。但是極端情況下，redis也是有可能會crash的。有時候因為種種原因，系統配置問題，磁碟空間寫滿了，程序許可權不夠等等，我們可能不會運氣那麼好，有乙個core檔案可以拿去除錯。這個時候，redis提供了幾種異常崩潰情況下的...

JNI崩潰除錯

jni崩潰了，系統日誌會列印堆疊資訊，所以第一步就是取日誌 adb shell logcat v threadtime d log.txt 然後找到日誌裡面的關鍵字backtrace例如我的日誌是這樣的 12 04 06 14 38.362 3773 3773 f debug backtrace 1...

Xcode 崩潰堆疊符號化,定位崩潰

首先，進行常識 腦補 1.符號表是什麼？dsym檔案其實是乙個目錄，在子目錄中包含了乙個16進製制的儲存函式位址對映資訊的中轉檔案，所有debug的symbols都在這個檔案中 包括檔名 函式名 行號等 所以也稱之為除錯符號資訊檔案。注意 來檢查 那麼，問題就來了！2.符號表有什麼用？實際上，使用x...