大內(nèi)高手—常見內(nèi)存錯誤
隨著諸如代碼重構(gòu)和單元測試等方法引入實踐，調(diào)試技能漸漸弱化了，甚至有人主張廢除調(diào)試器。這是有道理的，原因在于調(diào)試的代價往往太大了，特別是調(diào)試系統(tǒng)集成之后的BUG，一個BUG花了幾天甚至數(shù)周時間并非罕見。
而這些難以定位的BUG基本上可以歸為兩類：內(nèi)存錯誤和并發(fā)問題。而又以內(nèi)存錯誤最為普遍，即使是久經(jīng)沙場的老手，也有時也難免落入陷阱。前事不忘，后世之師，了解這些常見的錯誤，在編程時就加以注意，把出錯的概率降到最低，可以節(jié)省不少時間。
這些列舉一些常見的內(nèi)存錯誤，供新手參考。
1. 內(nèi)存泄露。
大家都知道，在堆上分配的內(nèi)存，如果不再使用了，應(yīng)該把它釋放掉，以便后面其它地方可以重用。在C/C++中，內(nèi)存管理器不會幫你自動回收不再使用的內(nèi)存。如果你忘了釋放不再使用的內(nèi)存，這些內(nèi)存就不能被重用，就造成了所謂的內(nèi)存泄露。
把內(nèi)存泄露列為首位，倒并不是因為它有多么嚴(yán)重的后果，而因為它是最為常見的一類錯誤。一兩處內(nèi)存泄露通常不至于讓程序崩潰，也不會出現(xiàn)邏輯上的錯誤，加上進程退出時，系統(tǒng)會自動釋放該進程所有相關(guān)的內(nèi)存，所以內(nèi)存泄露的后果相對來說還是比較溫和的。當(dāng)然了，量變會產(chǎn)生質(zhì)變，一旦內(nèi)存泄露過多以致于耗盡內(nèi)存，后續(xù)內(nèi)存分配將會失敗，程序可能因此而崩潰。
現(xiàn)在的PC機內(nèi)存夠大了，加上進程有獨立的內(nèi)存空間，對于一些小程序來說，內(nèi)存泄露已經(jīng)不是太大的威脅。但對于大型軟件，特別是長時間運行的軟件，或者嵌入式系統(tǒng)來說，內(nèi)存泄露仍然是致命的因素之一。
不管在什么情況下，采取比較謹(jǐn)慎的態(tài)度，杜絕內(nèi)存泄露的出現(xiàn)，都是可取的。相反，認(rèn)為內(nèi)存有的是，對內(nèi)存泄露放任自流都不是負(fù)責(zé)的。盡管一些工具可以幫助我們檢查內(nèi)存泄露問題，我認(rèn)為還是應(yīng)該在編程時就仔細(xì)一點，及早排除這類錯誤，工具只是用作驗證的手段。
2. 內(nèi)存越界訪問。
內(nèi)存越界訪問有兩種：一種是讀越界，即讀了不屬于自己的數(shù)據(jù)，如果所讀的內(nèi)存地址是無效的，程度立刻就崩潰了。如果所讀內(nèi)存地址是有效的，在讀的時候不會出問題，但由于讀到的數(shù)據(jù)是隨機的，它會產(chǎn)生不可預(yù)料的后果。另外一種是寫越界，又叫緩沖區(qū)溢出。所寫入的數(shù)據(jù)對別人來說是隨機的，它也會產(chǎn)生不可預(yù)料的后果。
內(nèi)存越界訪問造成的后果非常嚴(yán)重，是程序穩(wěn)定性的致命威脅之一。更麻煩的是，它造成的后果是隨機的，表現(xiàn)出來的癥狀和時機也是隨機的，讓BUG的現(xiàn)象和本質(zhì)看似沒有什么聯(lián)系，這給BUG的定位帶來極大的困難。
一些工具可以夠幫助檢查內(nèi)存越界訪問的問題，但也不能太依賴于工具。內(nèi)存越界訪問通常是動態(tài)出現(xiàn)的，即依賴于測試數(shù)據(jù)，在極端的情況下才會出現(xiàn)，除非精心設(shè)計測試數(shù)據(jù)，工具也無能為力。工具本身也有一些限制，甚至在一些大型項目中，工具變得完全不可用。比較保險的方法還是在編程是就小心，特別是對于外部傳入的參數(shù)要仔細(xì)檢查。
3. 野指針。
野指針是指那些你已經(jīng)釋放掉的內(nèi)存指針。當(dāng)你調(diào)用free(p)時，你真正清楚這個動作背后的內(nèi)容嗎？你會說p指向的內(nèi)存被釋放了。沒錯，p本身有變化嗎？答案是p本身沒有變化。它指向的內(nèi)存仍然是有效的，你繼續(xù)讀寫p指向的內(nèi)存，沒有人能攔得住你。
釋放掉的內(nèi)存會被內(nèi)存管理器重新分配，此時，野指針指向的內(nèi)存已經(jīng)被賦予新的意義。對野指針指向內(nèi)存的訪問，無論是有意還是無意的，都為此會付出巨大代價，因為它造成的后果，如同越界訪問一樣是不可預(yù)料的。
釋放內(nèi)存后立即把對應(yīng)指針置為空值，這是避免野指針常用的方法。這個方法簡單有效，只是要注意，當(dāng)然指針是從函數(shù)外層傳入的時，在函數(shù)內(nèi)把指針置為空值，對外層的指針沒有影響。比如，你在析構(gòu)函數(shù)里把this指針置為空值，沒有任何效果，這時應(yīng)該在函數(shù)外層把指針置為空值。
4. 訪問空指針。
空指針在C/C++中占有特殊的地址，通常用來判斷一個指針的有效性。空指針一般定義為0。現(xiàn)代操作系統(tǒng)都會保留從0開始的一塊內(nèi)存，至于這塊內(nèi)存有多大，視不同的操作系統(tǒng)而定。一旦程序試圖訪問這塊內(nèi)存，系統(tǒng)就會觸發(fā)一個異常。
操作系統(tǒng)為什么要保留一塊內(nèi)存，而不是僅僅保留一個字節(jié)的內(nèi)存呢？原因是：一般內(nèi)存管理都是按頁進行管理的，無法單純保留一個字節(jié)，至少要保留一個頁面。保留一塊內(nèi)存也有額外的好處，可以檢查諸如p=NULL; p[1]之類的內(nèi)存錯誤。
在一些嵌入式系統(tǒng)(如arm7)中，從0開始的一塊內(nèi)存是用來安裝中斷向量的，沒有MMU的保護，直接訪問這塊內(nèi)存好像不會引發(fā)異常。不過這塊內(nèi)存是代碼段的，不是程序中有效的變量地址，所以用空指針來判斷指針的有效性仍然可行。
在訪問指針指向的內(nèi)存時，在確保指針不是空指針。訪問空指針指向的內(nèi)存，通常會導(dǎo)致程度崩潰，或者不可預(yù)料的錯誤。
5. 引用未初始化的變量。
未初始化變量的內(nèi)容是隨機的(像VC一類的編譯器會把它們初始化為固定值，如0xcc)，使用這些數(shù)據(jù)會造成不可預(yù)料的后果，調(diào)試這樣的BUG也是非常困難的。
對于態(tài)度嚴(yán)謹(jǐn)?shù)某潭葐T來說，防止這類BUG非常容易。在聲明變量時就對它進行初始化，是一個編程的好習(xí)慣。另外也要重視編譯器的警告信息，發(fā)現(xiàn)有引用未初始化的變量，立即修改過來。
6. 不清楚指針運算。
對于一些新手來說，指針常常讓他們犯糊涂。
比如int *p = …; p+1等于(size_t)p + 1嗎
老手自然清楚，新手可能就搞不清了。事實上, p+n 等于 (size_t)p + n * sizeof(*p)
指針是C/C++中最有力的武器，功能非常強大，無論是變量指針還是函數(shù)指針，都應(yīng)該掌握都非常熟練。只要有不確定的地方，馬上寫個小程序驗證一下。對每一個細(xì)節(jié)都了然于胸，在編程時會省下不少時間。
7. 結(jié)構(gòu)的成員順序變化引發(fā)的錯誤。
在初始化一個結(jié)構(gòu)時，老手可能很少像新手那樣老老實實的，一個成員一個成員的為結(jié)構(gòu)初始化，而是采用快捷方式，如：
|
Structs
{
int l;
char* p;
};
intmain(intargc, char* argv[])
{
structss1 = {4, "abcd"};
return 0;
}
|
以上這種方式是非常危險的，原因在于你對結(jié)構(gòu)的內(nèi)存布局作了假設(shè)。如果這個結(jié)構(gòu)是第三方提供的，他很可能調(diào)整結(jié)構(gòu)中成員的相對位置。而這樣的調(diào)整往往不會在文檔中說明，你自然很少去關(guān)注。如果調(diào)整的兩個成員具有相同數(shù)據(jù)類型，編譯時不會有任何警告，而程序的邏輯上可能相距十萬八千里了。
正確的初始化方法應(yīng)該是（當(dāng)然，一個成員一個成員的初始化也行）：
|
structs
{
int l;
char* p;
};
intmain(intargc, char* argv[])
{
structss1 = {.l=4, .p = "abcd"};
structss2 = {l:4, p:"abcd"};
return 0;
}
|
8. 結(jié)構(gòu)的大小變化引發(fā)的錯誤。
我們看看下面這個例子：
|
structbase
{
intn;
};
structs
{
structbaseb;
intm;
};
|
在OOP中，我們可以認(rèn)為第二個結(jié)構(gòu)繼承了第一結(jié)構(gòu)，這有什么問題嗎？當(dāng)然沒有，這是C語言中實現(xiàn)繼承的基本手法。
現(xiàn)在假設(shè)第一個結(jié)構(gòu)是第三方提供的，第二個結(jié)構(gòu)是你自己的。第三方提供的庫是以DLL方式分發(fā)的，DLL最大好處在于可以獨立替換。但隨著軟件的進化，問題可能就來了。
當(dāng)?shù)谌皆诘谝粋€結(jié)構(gòu)中增加了一個新的成員int k;，編譯好后把DLL給你，你直接給了客戶了。程序加載時不會有任何問題，在運行邏輯可能完全改變！原因是兩個結(jié)構(gòu)的內(nèi)存布局重疊了。解決這類錯誤的唯一辦法就是全部重新相關(guān)的代碼。
解決這類錯誤的唯一辦法就是重新編譯全部代碼。由此看來，DLL并不見得可以動態(tài)替換，如果你想了解更多相關(guān)內(nèi)容，建議閱讀《COM本質(zhì)論》。
9. 分配/釋放不配對。
大家都知道m(xù)alloc要和free配對使用，new要和delete/delete[]配對使用，重載了類new操作，應(yīng)該同時重載類的delete/delete[]操作。這些都是書上反復(fù)強調(diào)過的，除非當(dāng)時暈了頭，一般不會犯這樣的低級錯誤。
而有時候我們卻被蒙在鼓里，兩個代碼看起來都是調(diào)用的free函數(shù)，實際上卻調(diào)用了不同的實現(xiàn)。比如在Win32下，調(diào)試版與發(fā)布版，單線程與多線程是不同的運行時庫，不同的運行時庫使用的是不同的內(nèi)存管理器。一不小心鏈接錯了庫，那你就麻煩了。程序可能動則崩潰，原因在于在一個內(nèi)存管理器中分配的內(nèi)存，在另外一個內(nèi)存管理器中釋放時出現(xiàn)了問題。
10. 返回指向臨時變量的指針
大家都知道，棧里面的變量都是臨時的。當(dāng)前函數(shù)執(zhí)行完成時，相關(guān)的臨時變量和參數(shù)都被清除了。不能把指向這些臨時變量的指針返回給調(diào)用者，這樣的指針指向的數(shù)據(jù)是隨機的，會給程序造成不可預(yù)料的后果。
下面是個錯誤的例子：
|
char* get_str(void)
{
charstr[] = {"abcd"};
returnstr;
}
int main(int argc, char* argv[])
{
char* p = get_str();
printf("%s\n", p);
return 0;
}
|
下面這個例子沒有問題，大家知道為什么嗎？
|
char* get_str(void)
{
char* str = {"abcd"};
returnstr;
}
intmain(intargc, char* argv[])
{
char* p = get_str();
printf("%s\n", p);
return 0;
}
|
11. 試圖修改常量
在函數(shù)參數(shù)前加上const修飾符，只是給編譯器做類型檢查用的，編譯器禁止修改這樣的變量。但這并不是強制的，你完全可以用強制類型轉(zhuǎn)換繞過去，一般也不會出什么錯。
而全局常量和字符串，用強制類型轉(zhuǎn)換繞過去，運行時仍然會出錯。原因在于它們是是放在.rodata里面的，而.rodata內(nèi)存頁面是不能修改的。試圖對它們修改，會引發(fā)內(nèi)存錯誤。
下面這個程序在運行時會出錯：
|
intmain(intargc, char* argv[])
{
char* p = "abcd";
*p = '1';
return 0;
}
|
12. 誤解傳值與傳引用
在C/C++中，參數(shù)默認(rèn)傳遞方式是傳值的，即在參數(shù)入棧時被拷貝一份。在函數(shù)里修改這些參數(shù)，不會影響外面的調(diào)用者。如：
|
#include <stdlib.h>
#include <stdio.h>
void get_str(char* p)
{
p = malloc(sizeof("abcd"));
strcpy(p, "abcd");
return;
}
int main(int argc, char* argv[])
{
char* p = NULL;
get_str(p);
printf("p=%p\n", p);
return 0;
}
|
在main函數(shù)里，p的值仍然是空值。
13. 重名符號。
無論是函數(shù)名還是變量名，如果在不同的作用范圍內(nèi)重名，自然沒有問題。但如果兩個符號的作用域有交集，如全局變量和局部變量，全局變量與全局變量之間，重名的現(xiàn)象一定要堅決避免。gcc有一些隱式規(guī)則來決定處理同名變量的方式，編譯時可能沒有任何警告和錯誤，但結(jié)果通常并非你所期望的。
下面例子編譯時就沒有警告：
t.c
|
#include <stdlib.h>
#include <stdio.h>
intcount = 0;
intget_count(void)
{
returncount;
}
|
main.c
|
#include <stdio.h>
extern int get_count(void);
int count;
int main(int argc, char* argv[])
{
count = 10;
printf("get_count=%d\n", get_count());
return 0;
}
|
如果把main.c中的int count;修改為int count = 0;，gcc就會編輯出錯，說multiple definition of `count'。它的隱式規(guī)則比較奇妙吧，所以還是不要依賴它為好。
14. 棧溢出。
我們在前面關(guān)于堆棧的一節(jié)講過，在PC上，普通線程的棧空間也有十幾M，通常夠用了，定義大一點的臨時變量不會有什么問題。
而在一些嵌入式中，線程的?？臻g可能只5K大小，甚至小到只有256個字節(jié)。在這樣的平臺中，棧溢出是最常用的錯誤之一。在編程時應(yīng)該清楚自己平臺的限制，避免棧溢出的可能。
15. 誤用sizeof。
盡管C/C++通常是按值傳遞參數(shù)，而數(shù)組則是例外，在傳遞數(shù)組參數(shù)時，數(shù)組退化為指針（即按引用傳遞），用sizeof是無法取得數(shù)組的大小的。
從下面這個例子可以看出：
|
voidtest(charstr[20])
{
printf("%s:size=%d\n", __func__, sizeof(str));
}
intmain(intargc, char* argv[])
{
charstr[20] = {0};
test(str);
printf("%s:size=%d\n", __func__, sizeof(str));
return 0;
}
|
[root@localhost mm]# ./t.exe
test:size=4
main:size=20
16. 字節(jié)對齊。
字節(jié)對齊主要目的是提高內(nèi)存訪問的效率。但在有的平臺(如arm7)上，就不光是效率問題了，如果不對齊，得到的數(shù)據(jù)是錯誤的。
所幸的是，大多數(shù)情況下，編譯會保證全局變量和臨時變量按正確的方式對齊。內(nèi)存管理器會保證動態(tài)內(nèi)存按正確的方式對齊。要注意的是，在不同類型的變量之間轉(zhuǎn)換時要小心，如把char*強制轉(zhuǎn)換為int*時，要格外小心。
另外，字節(jié)對齊也會造成結(jié)構(gòu)大小的變化，在程序內(nèi)部用sizeof來取得結(jié)構(gòu)的大小，這就足夠了。若數(shù)據(jù)要在不同的機器間傳遞時，在通信協(xié)議中要規(guī)定對齊的方式，避免對齊方式不一致引發(fā)的問題。
17. 字節(jié)順序。
字節(jié)順序歷來是設(shè)計跨平臺軟件時頭疼的問題。字節(jié)順序是關(guān)于數(shù)據(jù)在物理內(nèi)存中的布局的問題，最常見的字節(jié)順序有兩種：大端模式與小端模式。
大端模式是高位字節(jié)數(shù)據(jù)存放在低地址處，低位字節(jié)數(shù)據(jù)存放在高地址處。
小端模式指低位字節(jié)數(shù)據(jù)存放在內(nèi)存低地址處，高位字節(jié)數(shù)據(jù)存放在內(nèi)存高地址處；
比如long n = 0x11223344。
|
模式
|
第1個字節(jié)
|
第2個字節(jié)
|
第3個字節(jié)
|
第4個字節(jié)
|
|
大端模式
|
0x11
|
0x22
|
0x33
|
0x44
|
|
小端模式
|
0x44
|
0x33
|
0x22
|
0x11
|
在普通軟件中，字節(jié)順序問題并不引人注目。而在開發(fā)與網(wǎng)絡(luò)通信和數(shù)據(jù)交換有關(guān)的軟件時，字節(jié)順序問題就要特殊注意了。
18. 多線程共享變量沒有用valotile修飾。
在關(guān)于全局內(nèi)存的一節(jié)中，我們講了valotile的作用，它告訴編譯器，不要把變量優(yōu)化到寄存器中。在開發(fā)多線程并發(fā)的軟件時，如果這些線程共享一些全局變量，這些全局變量最好用valotile修飾。這樣可以避免因為編譯器優(yōu)化而引起的錯誤，這樣的錯誤非常難查。
可能還有其它一些內(nèi)存相關(guān)錯誤，一時想不全面，這里算是拋磚引玉吧，希望各位高手補充。
~~end~~