debug可以幫助熟悉系統(tǒng)，可是時(shí)間長(zhǎng)了會(huì)很疲卷，特別是機(jī)械的調(diào)試，如果還要面對(duì)雜亂的代碼，更是雪上加霜。所以要學(xué)著從debug中鉆探快樂，在系統(tǒng)的調(diào)試過程中發(fā)揮想象，嘗試不同的debug方法。

    最近看了《軟件調(diào)試實(shí)戰(zhàn)》，結(jié)合自己的經(jīng)歷，總結(jié)了一下：

    1. 與測(cè)試用例相關(guān)

       a. 如果不能達(dá)到“測(cè)試先行”，至少應(yīng)該在寫完代碼后有相對(duì)完整的測(cè)試用例。對(duì)于正確性的保證和以后重構(gòu)代碼都是有好處的。

       b. 每次添加新功能或修復(fù)了一個(gè)bug時(shí)，都應(yīng)該增加測(cè)試用例！A歷經(jīng)千辛萬(wàn)苦終于fix 了一個(gè)bug，很久很久以后，B覺得這段代碼需要改改，于是改了改，后來(lái)的結(jié)果還是改了，而且順利提交到了庫(kù)里（因?yàn)锳當(dāng)時(shí)遇到的bug 并沒有出現(xiàn)！）

       c. 回歸測(cè)試

         修改代碼后進(jìn)行回歸測(cè)試。每次提交一個(gè)版本后自動(dòng)進(jìn)行回歸測(cè)試，保證庫(kù)里的代碼的正確性。

       d. 簡(jiǎn)化測(cè)試用例

         好處：可以排除不起作用的因素；減少測(cè)試用例的運(yùn)行時(shí)間；最重要的是，使用測(cè)試用例更容易調(diào)試（誰(shuí)愿意處理那些填充了數(shù)百或數(shù)千項(xiàng)的數(shù)據(jù)容器呢？）

         方法如： 如果測(cè)試?yán)颖容^好改，可以將其改小；將輸入集改小

       e. 完成代碼，清理后重新運(yùn)行所有測(cè)試用例。

    2. 關(guān)于程序的編譯

      a. 重視編譯期間的warning，最好把warning數(shù)減為0. 不要忽略編譯器警告，即使它們可能是無(wú)害的。

eg：

int add(int a,int b){

        return a +b ;

}

結(jié)果頭文件里聲明成了 extern int add(long a,int b)

會(huì)調(diào)試死人啊，調(diào)程序的時(shí)候一看程序定義是對(duì)的啊，怎么傳的參數(shù)一下就變了；

b. 如果出現(xiàn)莫名其妙的錯(cuò)誤

      如果是用Makefile組織工程時(shí)，考慮make clean，有可能修改數(shù)據(jù)結(jié)構(gòu)或頭文件后改變了一些東西，但是由于一些未知原因該文件并未重新編譯。如果函數(shù)是C函數(shù)，有可能調(diào)用者和被 調(diào)用者的參數(shù)的成員和類型不同。如果一個(gè)類方法，則訪問任何類成員 都將發(fā)生錯(cuò)誤，因?yàn)檫@兩個(gè)類的內(nèi)存而已幾乎是完全不同的。這可能導(dǎo)致Segmentation falut,或是很久之后才能檢測(cè)到的內(nèi)存破壞。

3. 關(guān)于鏈接

a. 鏈接器的基本工作原理

       編譯器或匯編程序?qū)⒃创a轉(zhuǎn)換為機(jī)器代碼，并輸出對(duì)象誰(shuí)的。對(duì)象文件中包含符號(hào)（函數(shù)或變量），這些符號(hào)有的在本模塊定義的，有的在其他模塊定義的，鏈接器就在鏈接對(duì)象文件時(shí)把這些未定義的符號(hào)與定義它的模塊對(duì)應(yīng)起來(lái)。

b. 鏈接順序

     有庫(kù)和歸檔文件時(shí) 鏈接算法是不一樣的。    

     鏈接器參數(shù)順序很重要，對(duì)于編譯單元（如對(duì)象文件和庫(kù)）和搜索路徑來(lái)說(shuō)都是如此。

c. C++中使用C代碼時(shí)，用extern c{} 把C代碼包裝一下。

     關(guān)于 c++符號(hào)和名稱改編：C++允許重載函數(shù)，為了生成C++代碼元素的唯一符號(hào)，編譯器使一種稱為名稱改編（name mangling）的技術(shù)，它將對(duì)象的準(zhǔn)確規(guī)格說(shuō)明（如會(huì)員名空間和函數(shù)參數(shù)的個(gè)數(shù)及類型）編碼到符號(hào)中。（可以用c++filt解析出來(lái)~ eg: c++filt _Z9factoriali的結(jié)果為factorial(int)）

d. 環(huán)境變量

   LD_LIBRARY_PATH會(huì)影響動(dòng)態(tài)加載的庫(kù)，用LDD可以看到程序依賴哪個(gè)動(dòng)態(tài)庫(kù)

4. 自動(dòng)化測(cè)試

   讓一切自動(dòng)化起來(lái)。如果重復(fù)的做一件事，就很有必要考慮自動(dòng)化了。

5. 關(guān)于那些怪異的錯(cuò)誤

    在一些顯而易見有內(nèi)存問題的情況下，如：間歇故障和無(wú)法解釋的隨機(jī)行為，這時(shí)考慮使用內(nèi)存調(diào)試器了！

    如valgrind，很好用，也很簡(jiǎn)單。

    valgrind –tool=massif your_program 進(jìn)行內(nèi)存剖析（檢測(cè)內(nèi)存分配情況，優(yōu)化內(nèi)存使用）

    valgrind –tool=memcheck your_program 進(jìn)行內(nèi)存檢查（檢測(cè)無(wú)效的寫訪問，檢測(cè)對(duì)未初始化的內(nèi)存的讀取操作，檢測(cè)內(nèi)存泄露等）

    valgrind –tool=helgrind your_program 查找競(jìng)爭(zhēng)條件，可以用來(lái)輔助調(diào)試多線程程序

    valgrid –-db-attac=yes的功能很好用，可以將內(nèi)存高度器和源代碼測(cè)試器（如gdb）結(jié)合起來(lái)，這樣就可以即時(shí)查看當(dāng)時(shí)的變量的值，很好用！

6. 靜態(tài)檢查器

   作為常規(guī)軟件構(gòu)建過程中的一部分運(yùn)行，用于查找一些可通過靜態(tài)源代碼分析發(fā)現(xiàn)的特定bug。

7. 關(guān)于運(yùn)行時(shí)剖析工具

     不要編寫自己的運(yùn)行時(shí)剖析時(shí)工具：自己霞友云朋一的剖析 工具通常使用系統(tǒng)調(diào)用time()或ctime()來(lái)測(cè)量時(shí)間。這些系統(tǒng)調(diào)用的問題是開銷很高，而且準(zhǔn)確度低。另處在剖析期間要收集大量數(shù)據(jù)，可能會(huì)影響程序本身的行為。

8. 環(huán)境變量

  如程序的行為可能 依賴于當(dāng)前工作目錄。在linux上，目錄被注冊(cè)到環(huán)境變量CWD上。這個(gè)bug碰到過，還導(dǎo)致了死鎖。

9. 讀取恰當(dāng)?shù)腻e(cuò)誤消息

  某個(gè)地方出錯(cuò)時(shí)，滿屏都是錯(cuò)誤消息時(shí)，應(yīng)該重點(diǎn)關(guān)注哪些消息？

  Answer: 首先出現(xiàn)的那些消息！因?yàn)楹竺娴南⒂锌赡苁乔懊鎸?dǎo)致的。這和編譯出錯(cuò)時(shí)的情景一致：編譯錯(cuò)誤有很多，我們肯定會(huì)直覺地去尋找第一個(gè)出錯(cuò)的 地方，誰(shuí)知道是不是少了個(gè)括號(hào)導(dǎo)致后面一連串的錯(cuò)誤。

10. bug不會(huì)自動(dòng)消失

      如果某個(gè)版本有bug，update后，bug消失了，“真好！”，一定要弄清楚bug出現(xiàn)的原因是什么。以前遇到過一個(gè)bug，增加一條printf語(yǔ)句后，bug消失了！最后發(fā)現(xiàn)問題是數(shù)組越界了，而修改源代碼會(huì)導(dǎo)致代碼段，數(shù)據(jù)段的布局等改變，所以會(huì)導(dǎo)致偶爾對(duì)。（這種情況可以求助于內(nèi)存調(diào)試工具或者靜態(tài)檢查的工具）

11. 學(xué)習(xí)使用gcc, gdb,strace 等工具。（熟悉以后可以再挖掘挖掘，可能有驚喜）

12. cvs/svn commit之前一定要diff一下，看做了哪些修改，以避免不小心刪掉一些東西后，然后”被提交”了。

最后，最強(qiáng)大的工具不在計(jì)算機(jī)中，而是調(diào)試者的判斷力和分析技巧。

   參考資料：

   1. 《軟件調(diào)試實(shí)戰(zhàn)》：http://book.douban.com/subject/4231293/