程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> 更多編程語言 >> Delphi >> MemProof教程

MemProof教程

編輯:Delphi

簡介

MemProof(內存清道夫)是AutomatedQA出品的一款非常不錯的檢測內存洩漏和資源洩漏的免費調試工具,適合於WIN32平台下使用DELPHI/C++ BUILDER開發的應用程序。

利 用它可以方便的查找出 一些忘記釋放的指針以及資源。它通過在調試模式下運行目標程序,監視程序的創建和釋放操作,以達到檢測資源洩漏的效果。監測過程中它會根據資源類型計數, 每次創建後增加計數,釋放則遞減計數,最後程序結束根據計數即可判斷出資源的洩漏。

MemProof的原作者是Atanas Stoyanov,後加盟了AutomatedQA公司,他目前是大名鼎鼎的AQTIME軟件的主力開發者。MemProof已經很久沒有更新了,作者在AutomatedQA的官方網站上也推薦大家使用AQTIME(http://www.automatedqa.com/products/aqtime/memproofusers.asp),因為AQTIME包含了MemProof的所有功能,並且擁有很多MemProof所不具備的特性,如:更好的COM支持,結合MSDN獲 取幫助,平台測試等等。雖然有這麼多好處,但是AQTIME畢竟是收費的商業軟件,價格不 菲,而且體積相對龐大。對於我來說,更願意選擇MemProof。輕佻的體積,簡單的操 作,還是免費的(這條最關鍵~~)。當然,對於大的企業用戶來說,AQTIME也是個非常不錯的選擇。

使用方法

l 下載

官方網站上的最新版本為 (Build 0.950 July 19, 2004)

下載地址:http://www.automatedqa.com/products/memproof/index.asp

l 安裝

MemProof是一個綠色軟件,下載完成後解壓,運行MemProof.exe即可。

l 准備

MemProof要求目標程序帶有完整的調試信息。打開工程選項(Project-Options)

1、 Compiler面板

l 去掉Optimization(代碼優化)選項

l 選擇Stack Frames(為所有過程函數強制生成調用堆棧)選項

l 選擇Debug information (在DCU文件中生成調試信息)選項

l 選擇Use Debug DCUS(編譯時鏈接帶有調試信息的VCL DCU文件)選項

20120821020943403

2、 Linker面板

l 選擇Detailed(生成完整的MAP文 件,包含模塊、單元、過程等地址信息)選項

l 選擇Include TD32 debug info(將調試信息生成到可執行文件)選項

該選項會導致可執行文件體積增大,但不會影響運行效率以及內存占用, 建議在正式發布時不要帶上該選項。

\

l 開始

一切准備就緒,現在可以開始調試了。

下面是用於調試的一段測試程序:

新建一個空白工程,在OnCreate事件中加入以下代碼:

procedure TForm1.FormCreate(Sender: TObject);

begin

TFont.Create; //創 建一個TFONT對象,但不釋放

CloseHandle(0); //關 閉一個不存在的句柄

end;

再根據上面的介紹設置好工程選項。打開MemProof:

\

Resources – 資源的類型,包括Error(錯誤)、Pointers(指針)、Memory(內存)、GDI(畫布資源)、User(系 統對象)、Kernel(核心對象)、Registry(注冊表)。

Resources Count – 資源數目,Current#代表當前數目,Peak#代表峰值數目

Resources Size – 資源大小,Current#代表當前大小,Peak#代表峰值大小

選擇File-Open 打開要調試的 執行文件,再選擇Run-Run 開始運行,再正常退出目標程序,如果有資源洩漏MemProof會自動打開Resources Details面板:

\

MemProof共列出5個內存洩漏,我們可以看到每個內存洩漏都有詳細的調用棧情況,以及相對應的源碼位置。

有時它會提示我們找不到對應的源碼,這是應為沒有指定源碼搜索路徑 的原因。MemProof有兩個位置可以設置源碼搜索路徑,一個在Configure- Search Directories,一個在Projects-Search Directories。前者是設置全局路徑,後者是設置當前路徑。一般建議在前者中設置DELPHI的VCL以及共用庫代碼的路徑,後者 設置工程本身源碼的路徑。MemProof還為用戶提供了快捷搜索VCL源 碼路徑的按鈕Get Default for ,使用這個按鈕可以快捷的獲取DELPHI的Libray Path(有的用戶 安裝了VC覆蓋了默認調試工具選項,所以有可能得到的是VC的Libray Path,這種情況可以直接到DELPHI的Libray Path中去拷貝即可)。

另外MemProof還可以記錄上次的測試結果方便用戶做比較,以及過濾等功能。

如果需要測試動態連接庫,可以選擇Project-Parameters,在Host Applications中 選擇主體程序,如果需要帶命令行,則在Parameters中輸入命令行,然後就可以開始測試了,和DELPHI中調試的方法是一樣的。

MemProof不支持Attach Process的 調試方式,這是一個不足的地方。

使用其實非常簡單,一看就明白了,下面介紹些調試中的經驗技巧。

技 巧

l 漸進式測 試,從最易發現的錯誤開始解決

一個大型的軟件可能會有 很多洩漏或者錯誤,這個時候可以漸進式的來測試,第一次測試可以直接運行後立即退出,檢測在加載的過程中是否存在洩漏,然後逐一更正。再分功能模塊進行測 試,比如只針對某個功能進行操作,然後退出檢測該模塊是否存在洩漏,如果存在,更正。最後再進行整體測試。這樣可以避免一些關聯性錯誤導致重復測試,而且 可以節省測試時間,可以使測試更有針對性。

l 分模塊測 試,從單個的模塊開始解決

和上一條原則一樣,為了 縮小測試面。在Projects的Moudle Configers中 選擇測試的模塊,開始每次只選擇一個模塊針對性測試,最後再選擇所有模塊測試。

注意:不要選擇一些如:Ole32.dll、kernel32.dll等系統模塊。

l 錯誤優 先,發現錯誤與洩漏並存時,優先解決錯誤

測試過程中,

image

代表錯誤,這些錯誤往往是由於錯誤的使用系統API導 致,如:釋放不存在的句柄,訪問權限不夠的資源,傳遞了錯誤的調用參數等。這些錯誤往往會導致代碼沒有按照預計的方式運行,觸發一些內存洩漏。所以,需要 優先修正這些位置。

l 系統資源 優先,發現有GDI、User、Kernel、Registry等存在洩漏時優先 解決

系統資源洩漏往往是由於窗體、畫布等資源 沒有及時釋放,這些錯誤非常明顯,而且這種錯誤往往會帶有很多的Pointers、Memory洩漏,所以,優先修正。

經 驗

l 經過實際 證明,下列錯誤是可以忽略的

1、 VirtualAlloc(00000000,4096,4096,64) VirtualAlloc kernel32.dll

這是有名的4096字節內存洩漏問題,任何使用DELPHI的VCL編寫的WIN32程序都會存在,這是由 於在Classes單元中的MakeObjectInstance方法中使用VirtualAlloc分配了4096字節的內存,並沒有釋放。 這不是BUG,不釋放是有原因的,請參考這篇文章:

http://www.thedelphimagazine.com/samples/1328/article.htm

2、OpenFileMapping

OpenFileMapping(4,0,”SMBuffer”) 導致的錯誤是由於BDE數據庫引擎激活時,嘗試OpenFileMapping和Sql Monitor建立鏈接, 但是當Sql Monitor未運行時,這個mapping 並不存在,所以會導致錯誤。這個錯誤已經被VCL所捕獲處理。所以可以忽略。

3、 LoadCursor

VCL並不是完美的,有時運行程序出現很多LoadCursor錯誤也可以忽略。

4、 其他

還有更多的關於DELPHI和C++Builder本身導致的內存洩漏可以參見:

http://www.automatedqa.com/support/leaksd6.asp

l 發現洩漏 的位置在VCL單元中的時候,不要去考究VCL的 代碼,找到調用棧中涉及到的外部單元去檢查。相信VCL吧,絕大多數情況些它是不會導致內存 洩漏的。

缺 點

MemProof盡管非常優秀,同 樣存在不少缺陷。如上面提到的不能Attach Process,這樣就不能夠調試ISAPI、服務程序等;還有,當程序由於訪問保護內存、或強制結束進程等原因導致非正常退出時,MemProof將不會有任何結果報告;另外,MemProof的機制決定它不可能實現遠程調試;最後,MemProof是個免費性質的軟件,在幫 助支持方面做得不夠,連一個像樣的幫助都沒有,同類的商業軟件BoundCheker在這方面 做得非常不錯,每個錯誤都可以在幫助中得到詳細的解釋,MemProof的這個缺點導致新 手不容易上手。

總結

關於MemProof就介紹到這裡了。 總之,瑕不掩瑜,MemProof依然是廣大DELPHI/C++BUILER愛好者的開發利器。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved