debug可以幫助熟悉系統，可是時間長了會很疲卷，特別是機械的調試，如果還要面對雜亂的代碼，更是雪上加霜。所以要學著從debug中鉆探快樂，在系統的調試過程中發揮想象，嘗試不同的debug方法。

    最近看了《軟件調試實戰》，結合自己的經歷，總結了一下：

    1. 與測試用例相關

       a. 如果不能達到“測試先行”，至少應該在寫完代碼后有相對完整的測試用例。對于正確性的保證和以后重構代碼都是有好處的。

       b. 每次添加新功能或修復了一個bug時，都應該增加測試用例！A歷經千辛萬苦終于fix 了一個bug，很久很久以后，B覺得這段代碼需要改改，于是改了改，后來的結果還是改了，而且順利提交到了庫里（因為A當時遇到的bug 并沒有出現！）

       c. 回歸測試

         修改代碼后進行回歸測試。每次提交一個版本后自動進行回歸測試，保證庫里的代碼的正確性。

       d. 簡化測試用例

         好處：可以排除不起作用的因素；減少測試用例的運行時間；最重要的是，使用測試用例更容易調試（誰愿意處理那些填充了數百或數千項的數據容器呢？）

         方法如： 如果測試例子比較好改，可以將其改小；將輸入集改小

       e. 完成代碼，清理后重新運行所有測試用例。

    2. 關于程序的編譯

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

eg：

int add(int a,int b){

        return a +b ;

}

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

會調試死人啊，調程序的時候一看程序定義是對的啊，怎么傳的參數一下就變了；

b. 如果出現莫名其妙的錯誤

      如果是用Makefile組織工程時，考慮make clean，有可能修改數據結構或頭文件后改變了一些東西，但是由于一些未知原因該文件并未重新編譯。如果函數是C函數，有可能調用者和被 調用者的參數的成員和類型不同。如果一個類方法，則訪問任何類成員 都將發生錯誤，因為這兩個類的內存而已幾乎是完全不同的。這可能導致Segmentation falut,或是很久之后才能檢測到的內存破壞。

3. 關于鏈接

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

       編譯器或匯編程序將源代碼轉換為機器代碼，并輸出對象誰的。對象文件中包含符號（函數或變量），這些符號有的在本模塊定義的，有的在其他模塊定義的，鏈接器就在鏈接對象文件時把這些未定義的符號與定義它的模塊對應起來。

b. 鏈接順序

     有庫和歸檔文件時 鏈接算法是不一樣的。    

     鏈接器參數順序很重要，對于編譯單元（如對象文件和庫）和搜索路徑來說都是如此。

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

     關于 c++符號和名稱改編：C++允許重載函數，為了生成C++代碼元素的唯一符號，編譯器使一種稱為名稱改編（name mangling）的技術，它將對象的準確規格說明（如會員名空間和函數參數的個數及類型）編碼到符號中。（可以用c++filt解析出來~ eg: c++filt _Z9factoriali的結果為factorial(int)）

d. 環境變量

   LD_LIBRARY_PATH會影響動態加載的庫，用LDD可以看到程序依賴哪個動態庫

4. 自動化測試

   讓一切自動化起來。如果重復的做一件事，就很有必要考慮自動化了。

5. 關于那些怪異的錯誤

    在一些顯而易見有內存問題的情況下，如：間歇故障和無法解釋的隨機行為，這時考慮使用內存調試器了！

    如valgrind，很好用，也很簡單。

    valgrind –tool=massif your_program 進行內存剖析（檢測內存分配情況，優化內存使用）

    valgrind –tool=memcheck your_program 進行內存檢查（檢測無效的寫訪問，檢測對未初始化的內存的讀取操作，檢測內存泄露等）

    valgrind –tool=helgrind your_program 查找競爭條件，可以用來輔助調試多線程程序

    valgrid –-db-attac=yes的功能很好用，可以將內存高度器和源代碼測試器（如gdb）結合起來，這樣就可以即時查看當時的變量的值，很好用！

6. 靜態檢查器

   作為常規軟件構建過程中的一部分運行，用于查找一些可通過靜態源代碼分析發現的特定bug。

7. 關于運行時剖析工具

     不要編寫自己的運行時剖析時工具：自己霞友云朋一的剖析 工具通常使用系統調用time()或ctime()來測量時間。這些系統調用的問題是開銷很高，而且準確度低。另處在剖析期間要收集大量數據，可能會影響程序本身的行為。

8. 環境變量

  如程序的行為可能 依賴于當前工作目錄。在linux上，目錄被注冊到環境變量CWD上。這個bug碰到過，還導致了死鎖。

9. 讀取恰當的錯誤消息

  某個地方出錯時，滿屏都是錯誤消息時，應該重點關注哪些消息？

  Answer: 首先出現的那些消息！因為后面的消息有可能是前面導致的。這和編譯出錯時的情景一致：編譯錯誤有很多，我們肯定會直覺地去尋找第一個出錯的 地方，誰知道是不是少了個括號導致后面一連串的錯誤。

10. bug不會自動消失

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

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

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

最后，最強大的工具不在計算機中，而是調試者的判斷力和分析技巧。

   參考資料：

   1. 《軟件調試實戰》：http://book.douban.com/subject/4231293/