如何debug？(轉載)

本文屬於轉載，原文地址以下：

https://blog.csdn.net/zhao4zhong1/article/details/53078924

 

一.碼畜：靠編譯器幫本身查語法錯誤

消滅筆誤:編寫適合程序員的鍵盤練習

if (常量==變量或表達式)

使用goto接力超長的if,switch

連續的if仍是if elseif

多個條件的組合:精心的排版

多重括號的匹配

條件編譯

各類const:不要糾結各類常量了，這個世界上惟一不變的就是變化。用APIWriteProcessMemory還能修改正運行的其它進程的內存裏面的所謂常量呢！

 

查看宏展開後的.i文件：VC編譯選項加/EP /P（項目、屬性、配置屬性、C/C++、預處理器、預處理到文件：是，預處理取消顯示行號：是），從新編譯，查看宏展開後對應的.i文件。gcc加-E

 

偶遇到莫名其妙的編譯錯誤都是用「每次用/*...*/或#if 0...#endif註釋掉不一樣部分再從新編譯，直到定位到具體語法出錯的位置。」的方法解決的。

 

附加包含路徑、附加庫路徑、附加依賴庫的設置。

 

二.碼農：靠調試器幫本身查邏輯錯誤

for/while語句後多餘的分號

while/do while語句在語義上的歧義

條件斷點

消息斷點

數據斷點

__asm int3或DebugBreak()斷點

在內存窗口中觀察數據的原始字節形態

 

Call Stack:崩潰的時候在彈出的對話框按相應按鈕進入調試，按Alt+7鍵查看Call Stack即「調用堆棧」裏面從上到下列出的對應從裏層到外層的函數調用歷史。雙擊某一行可將光標定位到這次調用的源代碼或彙編指令處，看不懂時雙擊下一行，直到能看懂爲止。

 

「給定一個小點的輸入，完整單步跟蹤(同時按Alt+7鍵查看Call Stack裏面從上到下列出的對應從裏層到外層的函數調用歷史)一遍。」是理解遞歸函數工做原理的不二法門！

遞歸函數關注如下幾個因素

·退出條件

·參數有哪些

·返回值是什麼

·局部變量有哪些

·全局變量有哪些

·什麼時候輸出

·會不會致使堆棧溢出

語法糖越甜，編譯調試查錯越苦！

C++的隱藏調用:單步類的實例「構造」或「複製」或「做爲函數參數」或「做爲函數返回值返回」或「參加各類運算」或「退出做用域」的語句對應的彙編代碼幾步後，就會來到該類的「構造函數」或「複製構造函數」或「運算符重載」或「析構函數」對應的C/C++源代碼處。

 

任務管理器、VMMap、Process Monitor、Process Explorer、GDI泄露檢測工具、……

 

三.碼人：靠寫日誌幫本身查運營錯誤

CrashDump或Core的無力。

PDB的無力。

線上Debug的無力。

觀察複雜數據的無力。

多線程調試的無力。

調試時序高度依賴代碼的無力。

調試萬年一遇非法數據的無力。

 

有時不將「調用函數名字＋各參數值，進入函數後各參數值，中間變量值，退出函數前準備返回的值，返回函數到調用處後函數名字＋各參數值＋返回值」這些信息寫日誌到文件中是不管如何也發現不了問題在哪裏的，包括捕獲各類異常、寫日誌到屏幕、單步或設斷點或生成core或dmp文件、……這些方法都不行！

 

四.碼神：靠冥想和頓悟幫本身查不可再現錯誤

假死的各類緣由：

·控制循環的變量的取值範圍有符號/無符號,==/<=

·控制循環的變量沒變

·控制循環的變量被外部程序修改

·各類資源泄露

·死鎖

·網速變慢或網絡資源耗盡或網絡時通時斷

·權限、UAC、殺毒軟件實時防禦

·操做系統或軟件自動升級

·覺得系統時間不可逆

·覺得系統時間相關變量不會溢出（GetTickCount()約49.7天就歸0了！）

·……

不要企圖優雅的結束（由於這是不可能辦到的）

而要在爛的不能再爛的攤子上也能重整河山！