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

分配位置

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

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

　　#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，可能我們會擔心長度為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()示例那樣清晰無誤地進行識別。即便采用其它技術進行丟失檢測和消除，這些輸出表仍將有助于確定丟失是否已被消除。

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