《軟件調試實戰》摘要chap3-5

緣起

• 20181210開始看，最近要開始處理相關需求和bug單了，用這本書當藍本創建知識脈絡，以項目爲場景遇到問題google，而後再豐富這個脈絡，爭取一天一章吧。

內容

• 目錄 9/203

chap1

chap2

chap3 查找根源--源代碼調試器 29/203

• 3.一、可視化程序行爲

  • gdb，VisualStudio，後者常常用，但前者聽得多，用得極少。
  • dbx（Sun Solaris的命令行調試器），TotalView（用於Linux和MacOS的基於GUI的調試器），ARM RealView Development Suite和Lauterbach TRACE32 除了dbx，其它的都沒據說過

• 3.二、準備簡單的可預測的示例

  • [factorial.c]()

    • 沒有邊界值保護，健壯性沒有考慮全

• 3.三、使調試器與程序一塊兒運行

  • -g是進行調試的編譯器標誌，gcc -g -o factorial factorial.c
  • gdb factorial，而後輸入run 命令行參數，本例是run 1
  • run -1時報內存錯誤

• 3.四、學習在程序崩潰時執行棧跟蹤

  • C/C++程序的棧是一個內存片斷，用來存儲每一個活動的函數調用的棧幀（stack frame）。棧幀由返回地址、函數的參數和局部變量組成。
  • 棧跟蹤（stack trace）

  • gdb的棧跟蹤命令是bt，backtrace，或where。

    • 可使用up或down在棧中移動
• 3.五、學習使用斷點

• 3.六、學習在程序中導航

  • 命令

    • run
    • start沒必要搜索包含main()函數的文件，直到main()的第一行
    • pause
    • continue

  • 3種不一樣的步進模式

    • step-into step 進入函數調用的函數體
    • step-over next
    • step-out finish

• 3.七、學習檢查數據：變量和表達式

  • print n

• 3.八、一個簡單示例的調試會話

  • gdb factorial
  • start 13
  • next
  • next
  • print n
  • step
  • break 8

• 一點輸出

  • 算是複習一下gdb的用法吧，感受尚未看帖子來得直觀，本身也實踐了一下，明天繼續在項目中應用，而後有問題再百度。掌握命令。
  • visual Studio雖然項目有用到，但好像也不太能有體系的輸出，後期再查漏補缺吧。
  • 學習+實踐，用時38min，20181210晚上看的。

chap4 修復內存問題 39/203

• 4.一、C/C++中的內存管理--功能強大但很危險

  • 常見的內存訪問bug

    • 內存泄漏（memory leak） 運行時分配，但沒有釋放，會使可用主內存被耗盡。
    • 內存管理的錯誤使用（incorrect use of memory management） 屢次釋放一個內存塊
    • 緩衝區溢出（buffer overrun） 已分配的內存外部的內存被改寫或破壞
    • 讀取未初始化的內存（reading uninitiulized memory）

• 4.二、有效的內存調試器

  • gdb沒法有效找出內存相關的錯誤。
  • Purify,還有 Insure++，Valgrind和BoundsChecker
  • **對數組要使用delete[]

• 4.三、示例1：檢測內存訪問錯誤

  • [main1.c]
  • gcc -g main1.c
  • valgrind --tool=memcheck --leak-check=yes ./a.out

• 4.四、示例2：對內存分配/釋放的不完整調用

  • [main2.c]
  • 調試命令如上

• 4.五、結合使用內存調試器和源代碼測試器

  • 在使用Valgrind時，可使用--db-attach=yes選項來鏈接源代碼調試器。
  • 默認調試器GDB，可使用--db-command=<command>指定另外一個調試器。
  • Purify在報告錯誤以後當即調用purify_stop_here()函數。
  • Insure++裏調用_Insure_trap_error()函數。
• 4.六、減小干擾，排查錯誤

• 4.七、什麼時候使用內存調試器

  • 將軟件移植到新操做系統上時
  • 程序崩潰時
  • 調試奇怪的bug時
  • 爲迴歸測試的一部分

• 4.八、約束

  • 測試用例應該有很好的代碼覆蓋率

  • 提供更多計算機資源

    • 動態內存的使用顯著增長，通常會增長2~4倍。
    • 增長程序的運行時間，一般是一個數量級。
  • 可能不支持多線程
  • 對非標準內存處理程序的支持

• 一點收穫

  • valrind開始使用和實踐
  • 明確一下常見內存錯誤名詞的具體緣由，好比啥樣的表明「memory leak」
  • 使用內存分析器雖然能檢查問題，但也是有代價的，消耗內存和時間。
  • 本部分學習用時24min。

chap5 剖析內存的使用 49/203

• 5.一、基本策略--主要步驟

• 5.二、示例：分配數組

  • [testmalloc.c]
• 5.三、第1步：查找泄漏
• 5.四、第2步：設置指望值

• 5.五、第3步：測量內存使用

  • 5.5.1 使用多個輸入

  • 5.5.2 在固定時間間隔中止程序

    • 在UNIX中setenv或export
  • 5.5.3 用簡單工具測量內存使用
  • 5.5.4 使用top
  • 5.5.5 使用WindowsTaskManager
  • 5.5.6 爲testmalloc選擇相關輸入值
  • 5.5.7 肯定機器上的內存是如何被釋放的

  • 5.5.8 使用內存剖析工具

    • Windows中使用AQtime或Mpatrol
    • Linux中使用Massif或Mpatrol
    • valgrind --tool=massif ./testmalloc n 100000 8使用massif
• 5.六、第4步：查明大部份內存被哪些數據佔用了

• 5.七、綜合練習--genindex示例

  • 5.7.1 覈實沒有大的內存泄漏
  • 5.7.2 估計內存使用
  • 5.7.3 測量內存使用
  • 5.7.4 查找使用內存的數據結構

• 一點收穫

  • 確認了一下解決問題的思路或流程。
  • 瞭解到了massif的工具，但並無用呢。
  • 仍是須要在項目中應用，最早開始看書只能創建知識體系而已，還不足以解決項目中的問題。
  • 本部分學習用時13min。
  • 好比測量內存的使用，除了top命令外，我知道的招就沒有了。

履歷

學習記錄

• 20181210看了chap3
• 20181211看了chap四、5