本文將帶您了解一些良好的和內存相關的編碼實踐以將內存錯誤保持在控制范圍內內存錯誤是 C 和 C++ 編程的禍根它們很普遍認識其嚴重性已有二十多年但始終沒有徹底解決它們可能嚴重影響應用程序並且很少有開發團隊對其制定明確的管理計劃但好消息是它們並不怎麼神秘引言
C 和 C++ 程序中的內存錯誤非常有害它們很常見並且可能導致嚴重的後果來自計算機應急響應小組(請參見參考資料)和供應商的許多最嚴重的安全公告都是由簡單的內存錯誤造成的自從 年代末期以來C 程序員就一直討論此類錯誤但其影響在 年仍然很大更糟的是如果按我的思路考慮當今的許多 C 和 C++ 程序員可能都會認為內存錯誤是不可控制而又神秘的頑症它們只能糾正無法預防
但事實並非如此本文將讓您在短時間內理解與良好內存相關的編碼的所有本質
正確的內存管理的重要性
存在內存錯誤的 C 和 C++ 程序會導致各種問題如果它們洩漏內存則運行速度會逐漸變慢並最終停止運行;如果覆蓋內存則會變得非常脆弱很容易受到惡意用戶的攻擊從 年著名的莫裡斯蠕蟲攻擊到有關 Flash Player 和其他關鍵的零售級程序的最新安全警報都與緩沖區溢出有關大多數計算機安全漏洞都是緩沖區溢出Rodney Bates 在 年寫道
在可以使用 C 或 C++ 的地方也廣泛支持使用其他許多通用語言(如 Java?RubyHaskell C#PerlSmalltalk 等)每種語言都有眾多的愛好者和各自的優點但是從計算角度來看每種編程語言優於 C 或 C++ 的主要優點都與便於內存管理密切相關與內存相關的編程是如此重要而在實踐中正確應用又是如此困難以致於它支配著面向對象編程語言功能性編程語言高級編程語言聲明性編程語言和另外一些編程語言的所有其他變量或理論
與少數其他類型的常見錯誤一樣內存錯誤還是一種隱性危害它們很難再現症狀通常不能在相應的源代碼中找到例如無論何時何地發生內存洩漏都可能表現為應用程序完全無法接受同時內存洩漏不是顯而易見
因此出於所有這些原因需要特別關注 C 和 C++ 編程的內存問題讓我們看一看如何解決這些問題先不談是哪種語言
內存錯誤的類別
首先不要失去信心有很多辦法可以對付內存問題我們先列出所有可能存在的實際問題
內存洩漏
錯誤分配包括大量增加 free()釋放的內存和未初始化的引用
懸空指針
數組邊界違規
這是所有類型即使遷移到 C++ 面向對象的語言這些類型也不會有明顯變化;無論數據是簡單類型還是 C 語言的 struct或 C++ 的類C 和 C++ 中內存管理和引用的模型在原理上都是相同的以下內容絕大部分是純 C語言對於擴展到 C++ 主要留作練習使用
內存洩漏
在分配資源時會發生內存洩漏但是它從不回收下面是一個可能出錯的模型(請參見清單 )
清單 簡單的潛在堆內存丟失和緩沖區覆蓋
void f(char *explanation)
{
char p;
p = malloc();
(void) sprintf(p
The f error occurred because of %s
explanation);
local_log(p);
}
您看到問題了嗎?除非 local_log()對 free()釋放的內存具有不尋常的響應能力否則每次對 f的調用都會洩漏 字節在記憶棒增量分發數兆字節內存時一次洩漏是微不足道的但是連續操作數小時後即使如此小的洩漏也會削弱應用程序
在實際的 C 和 C++ 編程中這不足以影響您對 malloc()或 new的使用本部分開頭的句子提到了資源不是僅指內存因為還有類似以下內容的示例(請參見清單 )FILE句柄可能與內存塊不同但是必須對它們給予同等關注
清單 來自資源錯誤管理的潛在堆內存丟失
int getkey(char *filename)
{
FILE *fp;
int key;
fp = fopen(filename r);
fscanf(fp %d &key);
return key;
}
fopen的語義需要補充性的 fclose在沒有 fclose()的情況下C 標准不能指定發生的情況時很可能是內存洩漏其他資源(如信號量網絡句柄數據庫連接等)同樣值得考慮
內存錯誤分配
錯誤分配的管理不是很困難下面是一個示例(請參見清單 )
清單 未初始化的指針
void f(int datum)
{
int *p;
/* Uhoh! No one has initialized p */
*p = datum;
}
關於此類錯誤的好消息是它們一般具有顯著結果在 AIX 下對未初始化指針的分配通常會立即導致 segmentation fault錯誤它的好處是任何此類錯誤都會被快速地檢測到;與花費數月時間才能確定且難以再現的錯誤相比檢測此類錯誤的代價要小得多
在此錯誤類型中存在多個變種free()釋放的內存比 malloc()更頻繁(請參見清單 )
/* Allocate once free twice */
void f()
{
char *p;
p = malloc();
free(p);
free(p);
}
/* Allocate zero times free once */
void f()
{
char *p;
/* Note that p remains uninitialized here */
free(p);
}
這些錯誤通常也不太嚴重盡管 C 標准在這些情形中沒有定義具體行為但典型的實現將忽略錯誤或者快速而明確地對它們進行標記;總之這些都是安全情形
懸空指針
懸空指針比較棘手當程序員在內存資源釋放後使用資源時會發生懸空指針(請參見清單 )
清單 懸空指針
void f()
{
struct x *xp;
xp = (struct x *) malloc(sizeof (struct x));
xpq = ;
free(xp);
/* Problem! Theres no guarantee that
the memory block to which xp points
hasnt been overwritten */
return xpq;
}
傳統的調試難以隔離懸空指針由於下面兩個明顯原因它們很難再現
即使影響提前釋放內存范圍的代碼已本地化內存的使用仍然可能取決於應用程序甚至(在極端情況下)不同進程中的其他執行位置
懸空指針可能發生在以微妙方式使用內存的代碼中結果是即使內存在釋放後立即被覆蓋並且新指向的值不同於預期值也很難識別出新值是錯誤值懸空指針不斷威脅著 C 或 C++ 程序的運行狀態
數組邊界違規
數組邊界違規十分危險它是內存錯誤管理的最後一個主要類別回頭看一下清單 ;如果 explanation的長度超過 則會發生什麼情況?回答難以預料但是它可能與良好情形相差甚遠特別是C 復制一個字符串該字符串不適於為它分配的 個字符在任何常規實現中超過的字符會覆蓋內存中的其他數據內存中數據分配的布局非常復雜並且難以再現所以任何症狀都不可能追溯到源代碼級別的具體錯誤這些錯誤通常會導致數百萬美元的損失
內存編程的策略
勤奮和自律可以讓這些錯誤造成的影響降至最低限度下面我們介紹一下您可以采用的幾個特定步驟;我在各種組織中處理它們的經驗是至少可以按一定的數量級持續減少內存錯誤
編碼風格
編碼風格是最重要的我還從沒有看到過其他任何作者對此加以強調影響資源(特別是內存)的函數和方法需要顯式地解釋本身下面是有關標頭注釋或名稱的一些示例(請參見清單 )
清單 識別資源的源代碼示例
/********
*
*
* Note that any function invoking protected_file_read()
* assumes responsibility eventually to fclose() its
* return value UNLESS that value is NULL
*
********/
FILE *protected_file_read(char *filename)
{
FILE *fp;
fp = fopen(filename r);
if (fp) {
} else {
}
return fp;
}
/*******
* ** Note that the return value of get_message points to a
* fixed memory location Do NOT free() it; remember to
* make a copy if it must be retained *
********/
char *get_message()
{
static char this_buffer[];
(void) sprintf(this_buffer );
return this_buffer;
}
/********
*
* While this function uses heap memory and so
* temporarily might expand the overall memory
* footprint it properly cleans up after itself
*
********/
int f(char *item)
{
my_class c;
int result;
c = new my_class(item);
result = cx;
delete c;
return result;
}
/********
*
* Note that f() is documented to return a value
* which needs to be returned to heap; as f thinly
* wraps f any code which invokes f() must be
* careful to free() the return value
*
********/
int *f()
{
int *p;
p = f();
return p;
}
使這些格式元素成為您日常工作的一部分可以使用各種方法解決內存問題
專用庫
語言
軟件工具
硬件檢查器在這整個領域中我始終認為最有用並且投資回報率最大的是考慮改進源代碼的風格它不需要昂貴的代價或嚴格的形式;可以始終取消與內存無關的段的注釋但影響內存的定義當然需要顯式注釋添加幾個簡單的單詞可使內存結果更清楚並且內存編程會得到改進
我沒有做受控實驗來驗證此風格的效果如果您的經歷與我一樣您將發現沒有說明資源影響的策略簡直無法忍受這樣做很簡單但帶來的好處太多了
檢測
檢測是編碼標准的補充二者各有裨益但結合使用效果特別好機靈的 C 或 C++ 專業人員甚至可以浏覽不熟悉的源代碼並以極低的成本檢測內存問題通過少量的實踐和適當的文本搜索您能夠快速驗證平衡的 *alloc()和 free()或者 new和 delete的源主體人工查看此類內容通常會出現像清單 中一樣的問題
清單 棘手的內存洩漏
static char *important_pointer = NULL;
void f()
{
if (!important_pointer)
important_pointer = malloc(IMPORTANT_SIZE);
if (condition)
/* Ooops! We just lost the reference
important_pointer already held */
important_pointer = malloc(DIFFERENT_SIZE);
}
如果 condition為真簡單使用自動運行時工具不能檢測發生的內存洩漏仔細進行源分析可以從此類條件推理出證實正確的結論我重復一下我寫的關於風格的內容盡管大量發布的內存問題描述都強調工具和語言對於我來說最大的收獲來自軟的以開發人員為中心的流程變更您在風格和檢測上所做的任何改進都可以幫助您理解由自動化工具產生的診斷
靜態的自動語法分析
當然並不是只有人類才能讀取源代碼您還應使靜態語法分析成為開發流程的一部分靜態語法分析是 lint嚴格編譯和幾種商業產品執行的內容掃描編譯器接受的源文本和目標項但這可能是錯誤的症狀
希望讓您的代碼無 lint盡管 lint已過時並有一定的局限性但是沒有使用它(或其較高級的後代)的許多程序員犯了很大的錯誤通常情況下您能夠編寫忽略 lint的優秀的專業質量代碼但努力這樣做的結果通常會發生重大錯誤其中一些錯誤影響內存的正確性與讓客戶首先發現內存錯誤的代價相比即使對這種類別的產品支付最昂貴的許可費也失去了意義清除源代碼現在即使 lint標記的編碼可能向您提供所需的功能但很可能存在更簡單的方法該方法可滿足 lint並且比較強鍵又可移植
內存庫
補救方法的最後兩個類別與前三個明顯不同前者是輕量級的;一個人可以容易地理解並實現它們另一方面內存庫和工具通常具有較高的許可費用對部分開發人員來說它們需要進一步完善和調整有效地使用庫和工具的程序員是理解輕量級的靜態方法的人員可用的庫和工具給人的印象很深其作為組的質量很高但是即使最優秀的編程人員也可能會被忽略內存管理基本原則的非常任性的編程人員攪亂據我觀察普通的編程人員在嘗試利用內存庫和工具進行隔離工作時也只能感到灰心
由於這些原因我們催促 C 和 C++ 程序員為解決內存問題先了解一下自己的源在這完成之後才去考慮庫
使用幾個庫能夠編寫常規的 C 或 C++ 代碼並保證改進內存管理Jonathan Bartlett 在 developerWorks 的 評論專欄中介紹了主要的候選項可以在下面的參考資料部分獲得庫可以解決多種不同的內存問題以致於直接對它們進行比較是非常困難的;這方面的常見主題包括垃圾收集智能指針和智能容器大體上說庫可以自動進行較多的內存管理這樣程序員可以犯更少的錯誤
我對內存庫有各種感受他們在努力工作但我看到他們在項目中獲得的成功比預期要小尤其在 C 方面我尚未對這些令人失望的結果進行仔細分析例如業績應該與相應的手動內存管理一樣好但是這是一個灰色區域——尤其在垃圾收集庫處理速度緩慢的情況下通過這方面的實踐得出的最明確的結論是與 C 關注的代碼組相比C++ 似乎可以較好地接受智能指針
內存工具
開發真正基於 C 的應用程序的開發團隊需要運行時內存工具作為其開發策略的一部分已介紹的技術很有價值而且不可或缺在您親自嘗試使用內存工具之前其質量和功能您可能還不了解
本文主要討論了基於軟件的內存工具還有硬件內存調試器;在非常特殊的情況下(主要是在使用不支持其他工具的專用主機時)才考慮它們
市場上的軟件內存工具包括專有工具(如 IBM Rational Purify 和 Electric Fence)和其他開放源代碼工具其中有許多可以很好地與 AIX 和其他操作系統一起使用
所有內存工具的功能基本相同構建可執行文件的特定版本(很像在編譯時通過使用 g標記生成的調試版本)練習相關應用程序和研究由工具自動生成的報告請考慮如清單 所示的程序
清單 示例錯誤
int main()
{
char p[];
strcpy(p Hello world);
puts(p);
}
此程序可以在許多環境中運行它編譯執行並將Hello world\n打印到屏幕使用內存工具運行相同應用程序會在第四行產生一個數組邊界違規的報告在了解軟件錯誤(將十四個字符復制到了只能容納五個字符的空間中)方面這種方法比在客戶處查找錯誤症狀的花費小得多這是內存工具的功勞
結束語
作為一名成熟的 C 或 C++ 程序員您認識到內存問題值得特別關注通過制訂一些計劃和實踐可以找到控制內存錯誤的方法學習內存使用的正確模式快速發現可能發生的錯誤使本文介紹的技術成為您日常工作的一部分您可以在開始時就消除應用程序中的症狀否則可能要花費數天或數周時間來調試
From:http://tw.wingwit.com/Article/program/net/201311/12852.html
