套路很簡單，不外乎: 懷疑 排除 定位 修改 驗證。
舉個程式設計生涯碰到的比較詭異的問題做例子：
我司開發的某裝置採用了某著名嵌入式實時作業系統。
裝置執行過程中出現時鐘跑飛，程式不響應的現象，最可怕的是沒有規律（這四個字應該是程式設計師的噩夢）。
因為沒有規律，不知道怎麼再現，只好祭出懷疑大法。首先懷疑對時有問題，把對時功能和所有可能修改系統時鐘的地方都遮蔽後觀察，bug還是出現。然後就懵逼了，不知道該往哪懷疑，只好各種功能排列組合後分別遮蔽再觀察，bug依舊出現。
經過一段時間的折騰，懷疑是系統內部的問題。但是這特麼可是著名os，懷疑它有問題，心裡是打鼓的。後來有一次裝置出bug後，硬著頭皮扒拉出程式堆疊，發現time函式返回值似乎不對勁。反彙編time函式，裡面邏輯很簡單，就是比較系統ticks。這特麼會有什麼問題？
實在沒招了，再硬著頭皮把整個os+app映象反彙編，好在有符號表，於是在裡面挨個找ticks的引用。最後發現這個版本帶的tcp/ip協議棧在某些情況下會把ticks清零。當時心裡是不太願意相信的，這種nb os怎麼會有這麼低階的bug？死馬當活馬醫，初步判斷這就是導致bug的原因，但是問題又來了，沒有os原始碼，沒法修改，也就沒法驗證。最後實在沒轍，不用系統time函數了，自己在時鐘中斷裡做了一套tick，在這套新tick基礎上再做了一套time函式，總算是把問題解決了。後來搞到了系統原始碼，一查果然是協議棧坑爹。這個os還有個著名的優先順序反轉bug，坑了美帝的火星車。
所以，我覺得debug套路很簡單，只是有時候需要一點經驗，耐心和運氣。
套路很簡單，不外乎: 懷疑 排除 定位 修改 驗證。
舉個程式設計生涯碰到的比較詭異的問題做例子：
我司開發的某裝置採用了某著名嵌入式實時作業系統。
裝置執行過程中出現時鐘跑飛，程式不響應的現象，最可怕的是沒有規律（這四個字應該是程式設計師的噩夢）。
因為沒有規律，不知道怎麼再現，只好祭出懷疑大法。首先懷疑對時有問題，把對時功能和所有可能修改系統時鐘的地方都遮蔽後觀察，bug還是出現。然後就懵逼了，不知道該往哪懷疑，只好各種功能排列組合後分別遮蔽再觀察，bug依舊出現。
經過一段時間的折騰，懷疑是系統內部的問題。但是這特麼可是著名os，懷疑它有問題，心裡是打鼓的。後來有一次裝置出bug後，硬著頭皮扒拉出程式堆疊，發現time函式返回值似乎不對勁。反彙編time函式，裡面邏輯很簡單，就是比較系統ticks。這特麼會有什麼問題？
實在沒招了，再硬著頭皮把整個os+app映象反彙編，好在有符號表，於是在裡面挨個找ticks的引用。最後發現這個版本帶的tcp/ip協議棧在某些情況下會把ticks清零。當時心裡是不太願意相信的，這種nb os怎麼會有這麼低階的bug？死馬當活馬醫，初步判斷這就是導致bug的原因，但是問題又來了，沒有os原始碼，沒法修改，也就沒法驗證。最後實在沒轍，不用系統time函數了，自己在時鐘中斷裡做了一套tick，在這套新tick基礎上再做了一套time函式，總算是把問題解決了。後來搞到了系統原始碼，一查果然是協議棧坑爹。這個os還有個著名的優先順序反轉bug，坑了美帝的火星車。
所以，我覺得debug套路很簡單，只是有時候需要一點經驗，耐心和運氣。