基于嵌入式系統設計中查找內存丟失的策略方案

分配位置

有時(shí)，位置信息比類(lèi)型信息更為有效。幸而我們能夠靈活地使用宏定義，從而無(wú)須更換標記即可選擇這些信息。

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

　　#define mMalloc(size_t size)

　　mMallocLineNo(size, __LINE__,

　　__FILE__)

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

mMallocLineNo()函數是程序清單1中函數mMalloc()的變異?，F在我們期望像程序清單3那樣存儲行號和文件名信息，為保持額外信息，結構BlockEntry將具有如下形式：

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

　　typedef struct

　　{

　　void * addr;

　　size_t size;

　　int line;

　　char * file;

　　} BlockEntry;

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

通過(guò)為每個(gè)內存塊存儲行號和文件名，就能精確地定位任何分配的內存塊?？梢詾樗刑囟ㄩL(cháng)度的表項設計一個(gè)輸出行號和文件名為mDisplayLocatiON()的函數，這樣就能輕易地識別出長(cháng)度可疑的內存塊的來(lái)源。

再次回到表1，可能我們會(huì )擔心長(cháng)度為44的內存塊。為了更多地了解這些內存的來(lái)源，可以在函數main()的末尾添加如下代碼：

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

　　mDisplayLocation(44);

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

　　這能將行44輸出50遍。

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

　　line = 162, file = listing2.c

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

這清晰地表明內存塊在函數growForever()中分配。

可變的長(cháng)度

某些內存分配的長(cháng)度可以發(fā)生急劇變化，例如：

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

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

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

是分配一塊足以存儲字符串名和字符串截止符的內存的通用方法。在嵌入式系統中，不會(huì )經(jīng)常對字符串和文件進(jìn)行操作；數據結構的分配則不是這樣，例如：

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

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

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

如果假定Motor為存儲結構，那么上述分配將總是得到相同長(cháng)度的內存塊，在上面描述的函數中，將在輸出中更簡(jiǎn)便地識別出這些內存塊。

在分配可變長(cháng)度內存塊時(shí)，可以行號和文件名的組合為核心計算內存分配的計數。示例中，我們存儲了行號和文件名，但打印的總數則取決于長(cháng)度。通過(guò)行號和文件名的聚合分配將有助于在相同的位置將所有的分配組合起來(lái)，而不管分配的長(cháng)度如何。某些情況下，即便可變的長(cháng)度不成問(wèn)題，這樣的分析仍然能帶給我們更多的啟發(fā)。

內存表

任何含有內存丟失的代碼都將導致這里給出的內存表不斷增大，而且并非所有的丟失都能像growForever()示例那樣清晰無(wú)誤地進(jìn)行識別。即便采用其它技術(shù)進(jìn)行丟失檢測和消除，這些輸出表仍將有助于確定丟失是否已被消除。

這里給出的循環(huán)并不處理可變的輸入數據。在實(shí)際項目中，通常插入一些調用(如仿真鍵盤(pán)敲擊序列的調用)以模擬輸入。在實(shí)際系統中，還必須創(chuàng )建一些適當的輸入。除非自己希望改變代碼，否則完全無(wú)須訪(fǎng)問(wèn)導致內存丟失的代碼段。因此，這里的示例或許向大家提供了一個(gè)良好的開(kāi)端，但任何內存丟失仍然需要進(jìn)行一些檢測。