由于 C 和 C++ 程序中完全由程序員自主申請(qǐng)和釋放內(nèi)存,稍不注意,就會(huì)在系統(tǒng)中導(dǎo)入內(nèi)存錯(cuò)誤。同時(shí),內(nèi)存錯(cuò)誤往往非常嚴(yán)重,一般會(huì)帶來諸如系統(tǒng)崩潰,內(nèi)存耗盡這樣嚴(yán)重的 后果。本文將從靜態(tài)分析和動(dòng)態(tài)檢測(cè)兩個(gè)角度介紹在 Linux 環(huán)境進(jìn)行內(nèi)存泄漏檢測(cè)的方法,并重點(diǎn)介紹靜態(tài)分析工具 BEAM、動(dòng)態(tài)監(jiān)測(cè)工具 Valgrind 和 rational purify 的使用方法。相信通過本文的介紹,能給大家對(duì)處理其它產(chǎn)品或項(xiàng)目?jī)?nèi)存泄漏相關(guān)的問題時(shí)提供借鑒。
從 歷史上看,來自計(jì)算機(jī)應(yīng)急響應(yīng)小組和供應(yīng)商的許多最嚴(yán)重的安全公告都是由簡(jiǎn)單的內(nèi)存錯(cuò)誤造成的。自從 70 年代末期以來,C/C++ 程序員就一直討論此類錯(cuò)誤,但其影響在 2007 年仍然很大。與許多其他類型的常見錯(cuò)誤不同,內(nèi)存錯(cuò)誤通常具有隱蔽性,即它們很難再現(xiàn),癥狀通常不能在相應(yīng)的源代碼中找到。例如,無論何時(shí)何地發(fā)生內(nèi)存泄 漏,都可能表現(xiàn)為應(yīng)用程序完全無法接受,同時(shí)內(nèi)存泄漏不是顯而易見[1]。存在內(nèi)存錯(cuò)誤的 C 和 C++ 程序會(huì)導(dǎo)致各種問題。如果它們泄漏內(nèi)存,則運(yùn)行速度會(huì)逐漸變慢,并最終停止運(yùn)行;如果覆蓋內(nèi)存,則會(huì)變得非常脆弱,很容易受到惡意用戶的攻擊。
因 此,出于這些原因,需要特別關(guān)注 C 和 C++ 編程的內(nèi)存問題,特別是內(nèi)存泄漏。本文先從如何發(fā)現(xiàn)內(nèi)存泄漏,然后使用不同的方法和工具定位內(nèi)存泄漏,最后對(duì)這些工具進(jìn)行了比較,另外還簡(jiǎn)單介紹了資源泄 漏的處理(以句柄泄漏為例)。本文使用的測(cè)試平臺(tái)是:Linux (Redhat AS4)。但是這些方法和工具許多都不只是局限于 C/C++ 語(yǔ)言以及 linux 操作系統(tǒng)。
內(nèi)存泄漏一般指的是堆內(nèi)存的泄漏。堆內(nèi)存是指程序從堆中分配的、大小任意的(內(nèi)存塊的大小可以在程序 運(yùn)行期決定)、使用完后必須顯示的釋放的內(nèi)存。應(yīng)用程序一般使用malloc、realloc、new 等函數(shù)從堆中分配到一塊內(nèi)存,使用完后,程序必須負(fù)責(zé)相應(yīng)的調(diào)用 free 或 delete 釋放該內(nèi)存塊。否則,這塊內(nèi)存就不能被再次使用,我們就說這塊內(nèi)存泄漏了。
1. 如何發(fā)現(xiàn)內(nèi)存泄漏
有些 簡(jiǎn)單的內(nèi)存泄漏問題可以從在代碼的檢查階段確定。還有些泄漏比較嚴(yán)重的,即在很短的時(shí)間內(nèi)導(dǎo)致程序或系統(tǒng)崩潰,或者系統(tǒng)報(bào)告沒有足夠內(nèi)存,也比較容易發(fā) 現(xiàn)。最困難的就是泄漏比較緩慢,需要觀測(cè)幾天、幾周甚至幾個(gè)月才能看到明顯異?,F(xiàn)象。那么如何在比較短的時(shí)間內(nèi)檢測(cè)出有沒有潛在的內(nèi)存泄漏問題呢?實(shí)際上 不同的系統(tǒng)都帶有內(nèi)存監(jiān)視工具,我們可以從監(jiān)視工具收集一段時(shí)間內(nèi)的堆棧內(nèi)存信息,觀測(cè)增長(zhǎng)趨勢(shì),來確定是否有內(nèi)存泄漏。在 Linux 平臺(tái)可以用 ps 命令,來監(jiān)視內(nèi)存的使用,比如下面的命令 (觀測(cè)指定進(jìn)程的VSZ值):
ps -aux
2. 靜態(tài)分析
包括手動(dòng)檢測(cè)和靜態(tài)工具分析,這是代價(jià)最小的調(diào)試方法。
2.1 手動(dòng)檢測(cè)
當(dāng)使用 C/C++ 進(jìn)行開發(fā)時(shí),采用良好的一致的編程規(guī)范是防止內(nèi)存問題第一道也是最重要的措施。檢測(cè)是編碼標(biāo)準(zhǔn)的補(bǔ)充。二者各有裨益,但結(jié)合使用效果特別好。專業(yè)的 C 或 C++ 專業(yè)人員甚至可以瀏覽不熟悉的源代碼,并以極低的成本檢測(cè)內(nèi)存問題。通過少量的實(shí)踐和適當(dāng)?shù)奈谋舅阉?,您能夠快速?yàn)證平衡的 *alloc() 和 free() 或者 new 和 delete 的源主體。人工查看此類內(nèi)容通常會(huì)出現(xiàn)像清單 1 中一樣的問題,可以定位出在函數(shù) LeakTest 中的堆變量 Logmsg 沒有釋放。
清單1. 簡(jiǎn)單的內(nèi)存泄漏
#include
#include
#include
int LeakTest(char * Para)
{
if(NULL==Para){
//local_log("LeakTest Func: empty parameter/n");
return -1;
}
char * Logmsg = new char[128];
if(NULL == Logmsg){
//local_log("memeory allocation failed/n");
return -2;
}
sprintf(Logmsg,"LeakTest routine exit: '%s'./n", Para);
//local_log(Logmsg);
return 0;
}
int main(int argc,char **argv )
{
char szInit [] = "testcase1";
LeakTest(szInit);
return 0;
}
2.2 靜態(tài)代碼分析工具
代碼靜態(tài)掃描和分析的工具比較多,比如 splint, PC-LINT, BEAM 等。因?yàn)?BEAM 支持的平臺(tái)比較多,這以 BEAM 為例,做個(gè)簡(jiǎn)單介紹,其它有類似的處理過程。
BEAM 可以檢測(cè)四類問題: 沒有初始化的變量;廢棄的空指針;內(nèi)存泄漏;冗余計(jì)算。而且支持的平臺(tái)比較多。
BEAM 支持以下平臺(tái):
- Linux x86 (glibc 2.2.4)
- Linux s390/s390x (glibc 2.3.3 or higher)
- Linux (PowerPC, USS) (glibc 2.3.2 or higher)
- AIX (4.3.2+)
- Window2000 以上
清單2. 用作 Beam 分析的代碼
#include
#include
#include
int *p;
void
foo(int a)
{
int b, c;
b = 0;
if(!p) c = 1;
if(c > a)
c += p[1];
}
int LeakTest(char * Para)
{
char * Logmsg = new char[128];
if((Para==NULL)||(Logmsg == NULL))
return -1; sprintf(Logmsg,"LeakTest routine exit: '%s'./n", Para); return 0;
}
int main(int argc,char **argv )
{
char szInit [] = "testcase1";
LeakTest(szInit);
return 0;
}
下面以 X86 Linux 為例,代碼如清單 2,具體的環(huán)境如下:
OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 2)
GCC: gcc version 3.4.4
BEAM: 3.4.2; https://w3.eda.ibm.com/beam/
可以把 BEAM 看作一個(gè) C/C++ 編譯器,按下面的命令進(jìn)行編譯 (前面兩個(gè)命令是設(shè)置編譯器環(huán)境變量):
./beam-3.4.2/bin/beam_configure --c gcc
./beam-3.4.2/bin/beam_configure --cpp g++
./beam-3.4.2/bin/beam_compile --beam::compiler=compiler_cpp_config.tcl -cpp code2.cpp
從下面的編譯報(bào)告中,我們可以看到這段程序中有三個(gè)錯(cuò)誤:”內(nèi)存泄漏”;“變量未初始化”;“ 空指針操作”
"code2.cpp", line 10: warning: variable "b" was set but never used
int b, c;
^
BEAM_VERSION=3.4.2
BEAM_ROOT=/home/hanzb/memdetect
BEAM_DIRECTORY_WRITE_INNOCENTS=
BEAM_DIRECTORY_WRITE_ERRORS=
-- ERROR23(heap_memory) / memory leak / >>>ERROR23_LeakTest_7b00071dc5cbb458
"code2.cpp", line 24: memory leak
ONE POSSIBLE PATH LEADING TO THE ERROR:
"code2.cpp", line 22: allocating using `operator new[]' (this memory will not be freed)
"code2.cpp", line 22: assigning into `Logmsg'
"code2.cpp", line 24: deallocating `Logmsg' because exiting its scope (losing last pointer to the memory)
-- ERROR1 / uninitialized / >>>ERROR1_foo_60c7889b2b608
"code2.cpp", line 16: uninitialized `c'
ONE POSSIBLE PATH LEADING TO THE ERROR:
"code2.cpp", line 10: allocating `c'
"code2.cpp", line 13: the if-condition is false
"code2.cpp", line 16: getting the value of `c'
VALUES AT THE END OF THE PATH:
p != 0 -- ERROR2 / operating on NULL / >>>ERROR2_foo_af57809a2b615
"code2.cpp", line 17: invalid operation involving NULL pointer
ONE POSSIBLE PATH LEADING TO THE ERROR:
"code2.cpp", line 13: the if-condition is true (used as evidence that error is possible)
"code2.cpp", line 16: the if-condition is true
"code2.cpp", line 17: invalid operation []' involving NULL pointer
p'
VALUES AT THE END OF THE PATH:
c = 1 p = 0 a <= 0
2.3 內(nèi)嵌程序
可以重載內(nèi)存分配和釋放函數(shù) new 和 delete,然后編寫程序定期統(tǒng)計(jì)內(nèi)存的分配和釋放,從中找出可能的內(nèi)存泄漏?;蛘哒{(diào)用系統(tǒng)函數(shù)定期監(jiān)視程序堆的大小,關(guān)鍵要確定堆的增長(zhǎng)是泄漏而不是合理的內(nèi)存使用。這類方法比較復(fù)雜,在這就不給出詳細(xì)例子了。
3. 動(dòng)態(tài)運(yùn)行檢測(cè)
實(shí)時(shí)檢測(cè)工具主要有 valgrind, Rational purify 等。
3.1 Valgrind
valgrind 是幫助程序員尋找程序里的 bug 和改進(jìn)程序性能的工具。程序通過 valgrind 運(yùn)行時(shí),valgrind 收集各種有用的信息,通過這些信息可以找到程序中潛在的 bug 和性能瓶頸。
Valgrind 現(xiàn)在提供多個(gè)工具,其中最重要的是 Memcheck,Cachegrind,Massif 和 Callgrind。Valgrind 是在 Linux 系統(tǒng)下開發(fā)應(yīng)用程序時(shí)用于調(diào)試內(nèi)存問題的工具。它尤其擅長(zhǎng)發(fā)現(xiàn)內(nèi)存管理的問題,它可以檢查程序運(yùn)行時(shí)的內(nèi)存泄漏問題。其中的 memecheck 工具可以用來尋找 c、c++ 程序中內(nèi)存管理的錯(cuò)誤??梢詸z查出下列幾種內(nèi)存操作上的錯(cuò)誤:
- 讀寫已經(jīng)釋放的內(nèi)存
- 讀寫內(nèi)存塊越界(從前或者從后)
- 使用還未初始化的變量
- 將無意義的參數(shù)傳遞給系統(tǒng)調(diào)用
- 內(nèi)存泄漏
3.2 Rational purify
Rational Purify 主要針對(duì)軟件開發(fā)過程中難于發(fā)現(xiàn)的內(nèi)存錯(cuò)誤、運(yùn)行時(shí)錯(cuò)誤。在軟件開發(fā)過程中自動(dòng)地發(fā)現(xiàn)錯(cuò)誤,準(zhǔn)確地定位錯(cuò)誤,提供完備的錯(cuò)誤信息,從而減少了調(diào)試時(shí)間。同 時(shí)也是市場(chǎng)上唯一支持多種平臺(tái)的類似工具,并且可以和很多主流開發(fā)工具集成。Purify 可以檢查應(yīng)用的每一個(gè)模塊,甚至可以查出復(fù)雜的多線程或進(jìn)程應(yīng)用中的錯(cuò)誤。另外不僅可以檢查 C/C++,還可以對(duì) Java 或 .NET 中的內(nèi)存泄漏問題給出報(bào)告。
在 Linux 系統(tǒng)中,使用 Purify 需要重新編譯程序。通常的做法是修改 Makefile 中的編譯器變量。下面是用來編譯本文中程序的 Makefile:
CC=purify gcc
首先運(yùn)行 Purify 安裝目錄下的 purifyplus_setup.sh 來設(shè)置環(huán)境變量,然后運(yùn)行 make 重新編譯程序。
./purifyplus_setup.sh
下面給出編譯一個(gè)代碼文件的示例,源代碼文件命名為 test3.cpp. 用 purify 和 g++ 的編譯命令如下,‘-g’是編譯時(shí)加上調(diào)試信息。
purify g++ -g test3.cpp –o test
運(yùn)行編譯生成的可執(zhí)行文件 test,就可以得到圖1,可以定位出內(nèi)存泄漏的具體位置。
./test
清單3. Purify 分析的代碼
#include char * Logmsg;
int LeakTest(char * Para)
{
if(NULL==Para){
//local_log("LeakTest Func: empty parameter/n");
return -1;
}
Logmsg = new char[128];
for (int i = 0 ; i < 128; i++)
Logmsg[i] = i%64;
if(NULL == Logmsg){
//local_log("memeory allocation failed/n");
return -2;
}
sprintf(Logmsg,"LeakTest routine exit: '%s'./n", Para);
//local_log(Logmsg);
return 0;
}
int main(int argc,char **argv )
{
char szInit [] = "testcase1";
int i;
LeakTest(szInit);
for (i=0; i < 2; i++){
if(i%200 == 0)
LeakTest(szInit);
sleep(1);
} return 0;
}
需要指出的是,程序必須編譯成調(diào)試版本才可以定位到具體哪行代碼發(fā)生了內(nèi)存泄漏。即在 gcc 或者 g++ 中,必須使用 "-g" 選項(xiàng)。
purify 的輸出結(jié)果
結(jié)論
本文介紹了多種內(nèi)存泄漏,定位方法(包括靜態(tài)分析,動(dòng)態(tài)實(shí)時(shí)檢測(cè))。涉及到了多個(gè)工具,詳細(xì)描述的它們的用法、用途以及優(yōu)缺點(diǎn)。對(duì)處理其它產(chǎn)品或項(xiàng)目?jī)?nèi)存泄漏相關(guān)的問題有很好的借鑒意義。
--------------------內(nèi)存泄漏
在此,談?wù)摰氖浅绦蛟O(shè)計(jì)中內(nèi)存泄漏和錯(cuò)誤的問題,不過,并不是所有的程序都有這一問 題。首先,泄漏等一些內(nèi)存方面的問題在有的程序語(yǔ)言中是不容易發(fā)生的。這些程序語(yǔ)言一般都認(rèn)為內(nèi)存管理太重要了,所以不能由程序員來處理,最好還是由程序 語(yǔ)言設(shè)計(jì)者來處理這些問題,這樣的語(yǔ)言有Perl、Java等等。
然而,在一些語(yǔ)言(最典型的就是C和C++)中,程序語(yǔ)言的設(shè)計(jì)者也認(rèn) 為內(nèi)存管理太重要,但必需由開發(fā)人員自己來處理。內(nèi)存泄漏指的是程序員動(dòng)態(tài)分配了內(nèi)存,但是在使用完成后卻忘了將其釋放。除了內(nèi)存泄漏以外,在開發(fā)人員自 己管理內(nèi)存的開發(fā)中,緩沖溢出、懸擺指針等其它一些內(nèi)存的問題也時(shí)有發(fā)生。
問題緣何產(chǎn)生
為了讓程序能夠處理在編譯時(shí)無法預(yù)知 的數(shù)據(jù)占用內(nèi)存的大小,所以程序必需要從操作系統(tǒng)實(shí)時(shí)地申請(qǐng)內(nèi)存,這就是所謂的動(dòng)態(tài)內(nèi)存。這時(shí)候,就會(huì)出現(xiàn)程序申請(qǐng)到內(nèi)存塊并且使用完成后,沒有將其歸還 給操作系統(tǒng)的錯(cuò)誤。更糟的情況是所獲取的內(nèi)存塊的地址丟失,從而系統(tǒng)無法繼續(xù)識(shí)別、定位該內(nèi)存塊。還有其它的問題,比如試圖訪問已經(jīng)釋放的指針(懸擺指 針),再如訪問已經(jīng)被使用了的內(nèi)存(內(nèi)存溢出)的問題。
后果不容忽視
對(duì)于那些不常駐內(nèi)存的程序來說,由于執(zhí)行過程很短,所以 即使有漏洞可能也不會(huì)導(dǎo)致特別嚴(yán)重的后果。不過對(duì)于一些常駐內(nèi)存的程序(比如Web服務(wù)器Apache)來說,如果出現(xiàn)這樣的問題,后果將非常嚴(yán)重。因?yàn)?有問題的程序會(huì)不斷地向系統(tǒng)申請(qǐng)內(nèi)存,并且不釋放內(nèi)存,最終可能導(dǎo)致系統(tǒng)內(nèi)存耗盡而導(dǎo)致系統(tǒng)崩潰。此外,存在內(nèi)存泄漏問題的程序除了會(huì)占用更多的內(nèi)存外, 還會(huì)使程序的性能急劇下降。對(duì)于服務(wù)器而言,如果出現(xiàn)這種情況,即使系統(tǒng)不崩潰,也會(huì)嚴(yán)重影響使用。
懸擺指針會(huì)導(dǎo)致一些潛在的隱患,并且 這些隱患不容易暴發(fā)。它非常不明顯,因此很難被發(fā)現(xiàn)。在這三種存在的問題形式中,緩沖溢出可能是最危險(xiǎn)的。事實(shí)上,它可能會(huì)導(dǎo)致很多安全性方面的問題(一 個(gè)安全的程序包含很多要素,但是最重要的莫過于小心使用內(nèi)存)。正如上面所述,有時(shí)也會(huì)發(fā)生同一內(nèi)存塊被多次返還給系統(tǒng)的問題,這顯然也是程序設(shè)計(jì)上的錯(cuò) 誤。一個(gè)程序員非常希望知道在程序運(yùn)行的過程中,使用內(nèi)存的情況,從而能夠發(fā)現(xiàn)并且修正問題。
如何處理
現(xiàn)在已經(jīng)有了一些實(shí)時(shí) 監(jiān)測(cè)內(nèi)存問題的技術(shù)。內(nèi)存泄漏問題可以通過定時(shí)地終止和重啟有問題的程序來發(fā)現(xiàn)和解決。在比較新的Linux內(nèi)核版本中,有一種名為OOM(Out Of Memory )殺手的算法,它可以在必要時(shí)選擇執(zhí)行Killed等程序。懸擺指針可以通過定期對(duì)所有已經(jīng)返還給系統(tǒng)的內(nèi)存置零來解決。解決內(nèi)存溢出問題的方法則多種多 樣。
事實(shí)上,在程序運(yùn)行時(shí)來解決這些問題,顯然要麻煩得多,所以我們希望能夠在開發(fā)程序時(shí)就發(fā)現(xiàn)并解決這些問題。下面介紹一些可用的自由軟件。
工具一:垃圾回收器(GC)
在GCC(下載)工具包中,有一個(gè)“垃圾回收器(GC)”,它可以輕松檢測(cè)并且修正很多的內(nèi)存問題。目前該項(xiàng)目由HP的Hans-J.Boehm負(fù)責(zé)。
使用的技術(shù)
GC使用的是名為Boehm-Demers-Weiser的可以持續(xù)跟蹤內(nèi)存定位的技術(shù)。它的算法通過使用標(biāo)準(zhǔn)的內(nèi)存定位函數(shù)來實(shí)現(xiàn)。程序使用這些函數(shù) 進(jìn)行編譯,然后執(zhí)行,算法就會(huì)分析程序的操作。該算法非常著名并且比較容易理解,不會(huì)導(dǎo)致問題或者對(duì)程序有任何干擾。
性能
該工具有很好的性能,故可以有效提高程序效率。其代碼非常少并且可以直接在GCC中使用。
該工具沒有界面,使用起來比較困難,所以要想掌握它還是要花一些工夫的。一些現(xiàn)有的程序很有可能無法使用這個(gè)編輯器進(jìn)行配置。此外,為了讓所有的調(diào)用能 被捕獲,所有的內(nèi)存調(diào)用(比如malloc()和free())都必須要使用由GC提供的相應(yīng)函數(shù)來代替。我們也可以使用宏來完成這一工作,但還是覺得不 夠靈活。
結(jié)論
如果你希望能夠有跨平臺(tái)(體系結(jié)構(gòu)、操作系統(tǒng))的解決方案,那么就是它了。
工具二:Memprof
Memprof(下載)是一個(gè)非常具有吸引力且非常易于使用的軟件,它由Red Hat的Owen Talyor創(chuàng)立。這個(gè)工具是用于GNOME前端的Boehm-Demers-Weiser垃圾回收器。
使用的技術(shù)
就其核心技術(shù)來說,Memprof和上面提到的GC沒有什么本質(zhì)的不同。不過在實(shí)現(xiàn)這一功能時(shí),它是從程序中捕獲所有的內(nèi)存請(qǐng)示并且實(shí)時(shí)將其重定位到垃圾回收器。
性能
該工具的性能非常不錯(cuò),其GUI設(shè)計(jì)得也不錯(cuò)(如圖1所示)。這個(gè)工具直接就可以執(zhí)行,并且其工作起來無需對(duì)源代碼進(jìn)行任何修改。在程序執(zhí)行時(shí),這個(gè)工具會(huì)以圖形化的方式顯示內(nèi)存的使用情況,以幫助你了解程序運(yùn)行過程中內(nèi)存的申請(qǐng)情況。
圖1 Memprof的GUI
該工具目前只能運(yùn)行于x86和PPC體系結(jié)構(gòu)之上的Linux系統(tǒng)之中。如果你需要用于其它的平臺(tái),應(yīng)該想想使用其它的工具。該工具不是GTK應(yīng)用程 序,所以需要一個(gè)完整的GNOME環(huán)境。這樣就使得其不能靈活用于所有的地方。此外,該工具的開發(fā)工作進(jìn)展得也比較緩慢(現(xiàn)在是0.4.1版)。
結(jié)論
如果你喜歡GUI工具并且不介意只能用于Linux以及GNOME之下,該工具應(yīng)該可以說是非常不錯(cuò)。
-
源代碼
+關(guān)注
關(guān)注
96文章
2943瀏覽量
66617 -
代碼
+關(guān)注
關(guān)注
30文章
4722瀏覽量
68229 -
內(nèi)存泄漏
+關(guān)注
關(guān)注
0文章
39瀏覽量
9193 -
編譯程序
+關(guān)注
關(guān)注
0文章
12瀏覽量
4128
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論