c
／c++
記憶體問題檢查利器
——purify
一、引言
我們都知道軟體的測試（在以產品為主的軟體公司中叫做
qa—quality assessment
）佔了整個軟體工程的
30% -50%
，但有這麼一種說法，即使是最優秀測試專家設計出來的測試案例，也無法徹底地檢測到記憶體上的問題。
使用c/c++
開發的團隊一定有被其記憶體問題折磨過的經歷，記憶體問題一直是
c/c++
開發人員的心頭之痛。特別當程式越來越多時，類的繼承和關聯越來越多時，記憶體問題也就越來越多，很多時候，開發人員在不經意的時候就帶入了記憶體問題。這是c/c++世界中很難避免的東西，哪怕是有10年以上開發經驗的老手，也難以避免或是杜絕記憶體問題。
而且，記憶體的問題是讓人很難察覺的，特別是對於記憶體問題排名第一的
memory leak
來說，在幾萬行**中出現
memory leak
的機率幾乎是
100%
，而且要靠一般的手段是很難檢測出這種程式錯誤的。它並不像
「野指標」或是
「陣列越界
」那麼容易暴露出來（這些會讓程式異常退出，而
memory leak
則不會）。當你發現你的伺服器端的程式，每隔乙個月（或是更長的時間）就把伺服器上的記憶體全部耗盡時，讓伺服器有規律地每過幾個月就當機一次，那麼你的程式可能是中了
memory leak
了，同時，你會發現在數十萬行**中尋找這種
memory leak
無異***撈針。
於是，正如《黑客帝國
ii》中描述的那樣，當你的程式越來越大，越來越複雜的時候，你會發現程式就越來越不受你的控制，有一些讓你記憶體出現問題乃至讓你應用程式崩潰的變數，他們生存在系統的邊緣，你怎麼找也找不到，這種情況下，除了用程式測試程式，別無其它的方法。對於
c/c++
記憶體問題中的
memory leak
這種頂級殺手，那怕最牛的程式設計師再加上最牛的系統架構師也很難把其找出來，對此，我們只有依靠程式，用程式去尋找這種系統的
bug。這麼讓我們事半功倍。
在我們尋求解決記憶體問題的同時，讓我們所感到幸運的時，目前，已經有許多小的軟體可供我們選擇，如
mallocdebug
，valgrind
，kcachegrind
，dmalloc
，numega
，boundscheck
，parasoft
，insure++
等等，在這裡，我想向大家介紹的是
rational
公司（呵呵，應該是
ibm了）的
purify
，這是我覺得最專業，也是最強大的記憶體檢測工具。
purify
所支援的作業系統有
windows 2000/xp professional/nt
、sun solaris
、hp-ux
、sgi-irix
。我不知道其支不支援
linux
，但在其**上，我並沒有看到這樣的資訊，但又聽別人說他支援，所以在這裡我不敢斷言它不支援，想想要做
unix
下的軟體能有不支援
linux
的嗎？可能很少吧。
下面，是我所使用的
purify
的版本和執行
purify
的作業系統：
> purify -version
version 2003.06.00 solaris 2
> uname -a
sunos hostname 5.8 generic_108528-11 sun4u sparc sunw,ultra-60
我會基於這個版本向你介紹
purify
的強大功能。
二、purify簡介在
c/c++
的軟體開發中，沒有任何一種工具可以讓你的應用程式避免引入記憶體問題，但是我們可以使用諸如
purify
這樣的工具對已經做好了的程式進行記憶體問題的檢查。
purify
的強大之處是可以找到應用程式中全面的記憶體問題，並可以和
gdb/dbx
等偵錯程式以配合使用，讓你對你的記憶體錯誤一目了然。
purify
是乙個run-time
的工具，也就是說只有在程式執行過程中，根據程式的運**況來檢視在某種執行條件下程式是否有記憶體上的問題，它可以在乙個非常複雜的程式中查詢記憶體錯誤，包括那種多程序或多執行緒的程式，它也可以進行測試。
purify
對程式中的每乙個記憶體操作都進行檢測，並對精確報告記憶體出現錯誤的變數和語句，以提供出現錯誤原因的分析。
purify
主要檢測的是下面這些記憶體錯誤：
陣列記憶體是否越界讀/寫。
是否使用了未初始化的記憶體。
是否對已釋放的記憶體進行讀/寫。
是否對空指標進行讀/寫。
l
記憶體漏洞。
在軟體工程中，以我的經驗而言，最好是在編碼階段時就使用
purify
檢測記憶體存問題，一直到交給測試人員測試。請相信我，在乙個大型的
c/c++
軟體產品中，即使檢測出了記憶體問題，離真正地解決它還有一定的距離，所以為了讓這個「距離
」不算太遠，最好還是在功能模組完成時就進行
purify
的記憶體檢測。
一般而言，在軟體測試中，首要的是軟體的功能測試，然後是反面案例測試，再而是壓力測試。就我個人經驗而言，使用記憶體檢測工具的階段應該是編碼階段、模組合併後、以及程式邏輯測試完成以後，直到產品發布前，也要做乙個記憶體測試。
要使用purify
這個工具很簡單，首先在你安裝好了的
purify
的目錄上你會看到兩個
shell
指令碼：purifyplus_setup.csh
（對應於
c-shell
）purifyplus_setup.sh
（對應於標準
shell
）。你先執行一下這兩個指令碼，以便讓
purify
設定好一些環境引數，如：
> source purifyplus_setup.csh
而對於你的程式而言，你需要這樣使用：
> purify cc –g –o myprogram myprogram.c
> purify cc –g –c –o mylib.o mylib.c
就這麼簡單，然後你只要執行你的程式就行了，
purify
會向你提交乙份記憶體問題的報告清單，以供你分析。
purify
使用的是
oci（
object code insertion
）技術，它會在你的目標程式中插入一些它自己的函式，這些函式主要都是記憶體檢測的語句，這些語句將會放置在程式中所有，記憶體操作之前，一旦在程式執行時發現記憶體問題，
purify
所插入的這些語句就會向你報告。一般來說，所有的記憶體檢測工具都是這樣工作的。
當被purify
編譯過的程式執行時，
purify
會彈出乙個圖形介面的視窗，來向你報告記憶體問題。
purify
在報告記憶體問題的時候，可以指出源程式中哪個地方出現記憶體問題，但對於記憶體洩漏而言，它只能指出出現問題的記憶體是哪一塊，也就是指出記憶體是在**被分配的，
而不是指出記憶體洩露是如何發生的。這是比較合乎情理的，所以，即使你知道那塊記憶體發生了洩漏，你也不一定能找到究竟在什麼時候發生的。當然，如果你讓
purify
配合gdb
一起使用，那麼要找到這種問題的根本原因，也不是什麼困難的事情。
記憶體測試 記憶體洩露工具 LeakCanary
專案位址 接入方法 1.配置依賴 dependencies debugcompile com.squareup.leakcanary leakcanary android 1.4 beta2 releasecompile com.squareup.leakcanary leakcanary andr...
堆，棧，記憶體洩露,記憶體溢位介紹
簡單的可以理解為 heap 堆 是由malloc之類函式分配的空間所在地。位址是由低向高增長的。stack 棧 是自動分配變數，以及函式呼叫的時候所使用的一些空間。位址是由高向低減少的。一 預備知識 程式的記憶體分配 乙個由c c 編譯的程式占用的記憶體分為以下幾個部分 1 棧區 stack 由編譯...
堆，棧，記憶體洩露,記憶體溢位介紹
簡單的可以理解為 heap 是由malloc之類函式分配的空間所在地。位址是由低向高增長的。stack 是自動分配變數，以及函式呼叫的時候所使用的一些空間。位址是由高向低減少的。一 預備知識 程式的記憶體分配 乙個由c c 編譯的程式占用的記憶體分為以下幾個部分 1 棧區 stack 由編譯器自動分...