Global Sources
電子工程專輯
 
電子工程專輯 > 記憶體/儲存
 
 
記憶體/儲存  

嵌入式系統設計中查找記憶體丟失的策略

上網時間: 2003年01月25日     打印版  Bookmark and Share  字型大小:  

關鍵字:memory  記憶體  memory leak  記憶體丟失  iteration 

在嵌入式系統設計過程中,軟體工程師在動態記憶體管理中會遇到記憶體丟失的問題,本刊2003年1月上半期介紹了跟蹤記憶體丟失面臨的困難以及一種將堆疊中的記憶體碎片降至最少的解決方案,本期將討論怎樣才能找到導致記憶體丟失的代碼段,從而提高工程師檢測記憶體丟失的能力。

在嵌入式系統設計過程中,要利用數組保存記憶體分配的每一個塊記錄,在記憶體塊釋放的同時,也將該記錄從數組中刪除。在主循環的每次迴圈之後,分配的記憶體塊的總數目將列印出來。理想情況下,要按類型對這些記憶體塊排序,但指向malloc()和free()的調用則不包含任何類型資訊。記憶體分配的大小是最好的標識,因此成為設計工程師需要記錄的資訊。此外,還需要儲存分配的記憶體塊地址資訊,這樣,當調用釋放函數時,就可以方便地定位或刪除塊記錄。

在添加和刪除塊記錄時,還需要跟蹤每種大小的記憶體塊數目,程式的列表1提供了實現上述功能的代碼。

程式1:在添加和刪除塊記錄時,還需要跟蹤每種大小的記憶體塊數目。

隨著記憶體塊的分配和釋放,數組:


=======================


typedef struct


{


void * address;


size_t size;


} BlockEntry;


======================

跟蹤當前存在的所有記憶體塊。另一數組則跟蹤當前存在的每種大小的記憶體塊總數:


======================


typedef struct


{


int count;


size_t size;


} Counter;


======================

函數mDisplayTable()允許我們在每次主循環結束時輸出結果。如果printf()不可用,則可利用除錯器中斷系統並檢驗數組的內容。

上述代碼還必須使NUM_SIZES和NUM_BLOCKS足夠大,以處理系統中的大量記憶體分配;但也不能太大,從而導致在系統執行之前就已耗盡所有的RAM。

輸出

快速地瀏覽代碼,可以注意到結構類型Sensor的長度定義如下:


=======================


typedef struct


{


int offset;


int gain;


char name[10];


} Sensor;


======================

假定int為32位元數據,那麼Sensor的長度將為18 (4 + 4 + 10),但在測試中,結果顯示為20。編譯器可以在儲存結構的數據成員之間自由地添加填充,以將對齊強制設定為一個字邊界。特殊情況下,每個字段開始於一個已存在的字邊界,那麼為什麼還需要填充呢?填充添加在儲存結構的最末端,如果聲明了一個數組Sensor,那麼該數組的所有成員(而不僅僅是第一個成員)將會進行字對齊。根據處理器的不同,字對齊的速度將有所差異,有時這些編譯器將提供可根據速度選擇字對齊長度的切換開關。在任何情形下,最好不要根據源代碼的定義對儲存結構的長度作任何假設。

下面考察當使用這些函數時,將得到何種類型的輸出。程式清單2給出了一個顯示儲存動態記憶體方式的示例。程式清單2將通常作為主外部循環的迴圈了10次,並在每次迴圈的末尾,調用函數mDisplay-Table()輸出分配的記憶體塊情況。

程式2:顯示儲存動態記憶體方式的示例。

許多記憶體塊均在初始化階段進行分配,但我們對這些記憶體塊並不感興趣,因為這段代碼將不會重覆,因此不會產生記憶體丟失。由於我們並不希望這些記憶體分配導致分配表混亂,因此在啟動感興趣的迴圈之前需要將該分配表清空。為了清空分配表,需要調用函數mClearTable()。

主循環調用的三個不同的函數

函數replacer():指示了一個用來分配記憶體塊並且直到出現循環迴圈才釋放的指標。如果檢驗主循環中的迴圈,可以發現分配的記憶體塊並未釋放。通過監控總數為20的記憶體塊,從表1可以看出,每次迴圈之後的記憶體塊總數都為1,因此沒有出現記憶體丟失。

函數growAndShrink():管理長度為24個結構體的鏈表,該鏈表的長度將隨時間產生變化,但我們並不希望鏈表無限成長。通過檢驗總數為24的記憶體塊,我們可以發現,雖然任意時間記憶體塊的數目都可能產生變化,但決不會超過25個。

函數growForever():處理記憶體塊長度為44的情形。這?我們可以非常清晰地看到,分配的記憶體塊數目在持續成長。當首次觀察該表時,可能無法找到表的源頭。我們首先只能快速而粗略對mMalloc()上的條件斷點進行檢驗,該斷點只有當長度參數達到44時才觸發。當到達該斷點時,可以檢驗堆疊,以確定進行記憶體分配的地方。工程師完全能夠多次執行這樣的作業,因為這種長度的記憶體塊可在多處進行分配。

嚴格地說,在函數growForever()中分配的記憶體不是丟失,因為所有分配的記憶體塊均帶有引用,因此理論上可以在後來釋放。如果特定應用這樣做,那麼結果就非常明顯。

長度是關鍵因素

當不同類型的對象共享相同長度的記憶體時,上述技術就不那麼有效了。實際中碰到這樣的情形並不多,但即便可能引發問題,仍然還有很多別的選擇。

更為先進的方法則是為每個記錄儲存類型資訊。這並不困難,但我卻不願採用這種方法,因為該方法要求為函數mMalloc()的標記添加一些新東西。我們可以定義一個列出所有可能分配的類型的枚舉類型。在每次調用函數mMalloc()時,將傳遞一個附加的參數,並且該參數為枚舉類型中的一個元素。如果在表中該參數連同地址一起被儲存,那麼總能識別出這類對象。

這也使得我們可以將分配長度不同,但類型相關(如可變長度的字符數組)的記憶體塊鏈接起來。

C++通過使我們重載或刪除按類基(per-class basis)而使得這種方法更加簡便易行。儘管這是一種有效的方法,但這?我仍然不會採用這種方法,因為我更傾向採用適合C語言環境的技術。

分配位置

有時,位置資訊比類型資訊更為有效。幸而我們能夠靈活地使用巨集定義,從而無須更換標記即可選擇這些資訊。


==========================


#define mMalloc(size_t size)


mMallocLineNo(size, __LINE__,


__FILE__)


=========================

mMallocLineNo()函數是程式清單1中函數mMalloc()的變異。現在我們期望像程式清單3那樣儲存行號和文件名資訊,為保持額外資訊,結構BlockEntry將具有如下形式:


=========================


typedef struct


{


void * addr;


size_t size;


int line;


char * file;


} BlockEntry;


==========================

通過為每個記憶體塊儲存行號和文件名,就能精確地定位任何分配的記憶體塊。可以為所有特定長度的表項設計一個輸出行號和文件名為mDisplayLocation()的函數,這樣就能輕易地識別出長度可疑的記憶體塊的來源。表1:通過監控總數為20的記憶體塊,每次迴圈之後的記憶體塊總數都為1,因此沒有出現記憶體丟失。

再次回到表1,可能我們會擔心長度為44的記憶體塊。為了更多地了解這些記憶體的來源,可以在函數main()的末尾添加如下代碼:


========================


mDisplayLocation(44);


=======================

這能將行44輸出50遍。


=======================


line = 162, file = listing2.c


=======================

這清晰地顯示記憶體塊在函數growForever()中分配。

可變的長度

某些記憶體分配的長度可以產生急劇變化,例如:


==========================


char *p = malloc(strlen(name)+1);


==========================

是分配一塊足以儲存字符串名和字符串截止符的記憶體的通用方法。在嵌入式系統中,不會經常對字符串和文件進行作業;數據結構的分配則不是這樣,例如:


==========================


Motor *m = malloc(sizeof(Motor));


==========================

如果假定Motor為儲存結構,那麼上述分配將總是得到相同長度的記憶體塊,在上面描述的函數中,將在輸出中更簡便地識別出這些記憶體塊。

在分配可變長度記憶體塊時,可以行號和文件名的組合為核心計算記憶體分配的計數。示例中,我們儲存了行號和文件名,但列印的總數則取決於長度。通過行號和文件名的聚合分配將有助於在相同的位置將所有的分配組合起來,而不管分配的長度如何。某些情況下,即便可變的長度不成問題,這樣的分析仍然能帶給我們更多的啟發。

記憶體表

任何含有記憶體丟失的代碼都將導致這?給出的記憶體表不斷增大,而且並非所有的丟失都能像growForever()示例那樣清晰無誤地進行識別。即便採用其它技術進行丟失檢測和消除,這些輸出表仍將有助於確定丟失是否已被消除。

這?給出的循環並不處理可變的輸入數據。在實際項目中,通常插入一些調用(如模擬鍵盤敲擊序列的調用)以類比輸入。在實際系統中,還必須建立一些適當的輸入。除非自己希望改變代碼,否則完全無須存取導致記憶體丟失的代碼段。因此,這?的示例或許向大家提供了一個良好的開端,但任何記憶體丟失仍然需要進行一些檢測。欲了解更多資訊請查閱www.panelsoft.com/murphyslaw。

參考文獻

1. Eckel, Bruce. Thinking in C++. Upper Saddle River, NJ: Prentice Hall, 2000.


2. Murphy, Niall. "Assert Yourself," Embedded Systems Programming, Map. 27.y 2001,

作者簡介:

Niall
Murphy為用戶介面和醫療系統編寫軟體已經10年。他是《為嵌入式用戶介面設計軟體》一書的作者。Murphy非常歡迎讀者來信,可透過nmurphy@panelsoft.com與他聯繫。





投票數:   加入我的最愛
我來評論 - 嵌入式系統設計中查找記憶體丟失的策略
評論:  
*  您還能輸入[0]個字
*驗證碼:
 
論壇熱門主題 熱門下載
 •   將邁入40歲的你...存款多少了  •  深入電容觸控技術就從這個問題開始
 •  我有一個數位電源的專利...  •  磷酸鋰鐵電池一問
 •   關於設備商公司的工程師(廠商)薪資前景  •  計算諧振轉換器的同步整流MOSFET功耗損失
 •   Touch sensor & MEMS controller  •  針對智慧電表PLC通訊應用的線路驅動器
 •   下週 深圳 llC 2012 關於PCB免費工具的研討會  •  邏輯閘的應用


EE人生人氣排行
 
返回頁首