有一定C++開發(fā)經(jīng)驗的同學(xué)大多數(shù)踩過內(nèi)存破壞的坑，有這么幾種現(xiàn)象：

比如某個變量整形，在程序中只可能初始化或者賦值為1或者2， 但是在使用的時候卻發(fā)現(xiàn)其為0或者其他的情況。對于其他類型，比如字符串等，可能出現(xiàn)了一種出乎意料的值！

程序在堆上申請內(nèi)存或者釋放內(nèi)存的時候，在內(nèi)存充足的情況下，居然出現(xiàn)了堆錯誤。

當(dāng)出現(xiàn)以上場景的時候，你該思考一下，是不是出現(xiàn)了內(nèi)存破壞的情況了。而本文主要通過展示和分析常見的三種內(nèi)存破壞導(dǎo)致覆蓋相鄰變量的場景，讓讀者在碰到類似的場景，不至于束手無策。而對于堆上的內(nèi)存破壞，很常見并且棘手的場景，本人將在后續(xù)的文章和大家分享。

1. 內(nèi)存破壞之強制類型轉(zhuǎn)換

大家都知道不匹配的類型強制轉(zhuǎn)換會帶來一些bug，比如int和unsigned int互相轉(zhuǎn)換，又或者int和__int64強行轉(zhuǎn)換。是不是每次當(dāng)讀起這類文章起來如雷貫耳，但是當(dāng)自己去寫代碼的時候還是容易犯錯？這也就是為什么C++容易寫出坑的原因，明知可能有錯，還難以避免。這往往是因為真實的項目中復(fù)雜程度，往往讓人容易忽略這些細節(jié)。

不少老的工程代碼還是采用VC6編譯，為了安全問題或者使用C++新特性需要將VC6升級到更新的Visual Studio。接下來要介紹的一個樣例程序，就是隱藏于代碼中的一個問題，如果從VC6升級到VS2017的時候會帶來問題嗎？可以先找找看：

#include 《iostream》#include 《time.h》class DemoClass

{public：

DemoClass（） ： m_bInit（true）， m_tRecordTime（0）

{

time（（time_t *）（&m_tRecordTime））;

};

void DoSomething（）

{

if （m_bInit）

std：：cout 《《 “Do Task！” 《《 std：：endl;

}

private：

int m_tRecordTime;

bool m_bInit;

};

int main（）

{

DemoClass testObj;

testObj.DoSomething（）;

return 0;

}

Do Task！這個字符串會不會打印出來呢？ 可以發(fā)現(xiàn)這段程序在VC6中可以打印出來，但是在VS2017中卻打印不出來了。那是因為如下原因：

函數(shù)原型time_t time（ time_t *destTime ）;，在VC6中time_t默認是32位，而在VS2017中默認是64位。早期程序以為32位中表達最大的時間是2038年，那時候完全夠用，但隨著計算機本身的發(fā)展64位逐漸成為主流time_t在最新的編譯器中也默認采用64位，這樣時間完全夠用以億年為單位了，那時候計算機發(fā)展超出我們想象了。

程序的問題所在m_tRecordTime采用的是int類型，默認為32位，那么其地址作為time_t time（ time_t *destTime ）;函數(shù)實參后，在VC6中time_t本身為32位自然也不會出錯，但是在VS2017中因為time_t為64位，則time（（time_t *）（&m_tRecordTime））;后寫入了一個64位的值。結(jié)合下圖，看下這個對象的內(nèi)存布局，m_bInit的值將會被覆蓋，而這里原先的m_bInit的值為1，被覆蓋為0，從而導(dǎo)致內(nèi)存破壞，導(dǎo)致程序執(zhí)行意想不到的結(jié)果。這里只是不輸出，那在真實程序中，可能會導(dǎo)致某個邏輯錯亂，發(fā)生嚴重的問題。

這個問題修改自然比較簡單，將m_tRecordTime定義為time_t類型就可以了。如果有類似的問題發(fā)生的時候，比如這個變量的可疑的發(fā)生了不該有的變化的時候，你可以查看下這個變量定義的附近是否有內(nèi)存的操作可能產(chǎn)生溢出，找到問題所在。因為內(nèi)存上溢的比較多，一般可以查看下定義在當(dāng)前出現(xiàn)問題的變量的低地址出的變量操作，是否存在可疑的地方。最后，針對這種場景，我們是不是也可以得到一些收獲呢，個人總結(jié)如下兩點：

在定義類型的時候，盡量和原始類型一致，比如這里的time_t有些程序員可能慣性的認為就是32位，那就定義一個時間戳的時候就定義為int了，而我們要做的應(yīng)該是和原始類型匹配（也就是函數(shù)的輸入類型），將其定義為time_t，于此類似的還有size_t等，這樣可以避免未來在數(shù)據(jù)集變化或者做平臺遷移的時候造成不必要的麻煩。

在有一些復(fù)雜的場景的下，也許你不得不做類型轉(zhuǎn)換，而這個時候就格外的需要注意或者了解清楚，轉(zhuǎn)換帶來的情況和后果，保持警惕，否則就可能是一個潛在的bug。這和開車一樣，當(dāng)你開車的時候如果看到前方車輛忽然產(chǎn)生一個不合常理的變道行為，首先要做的不是噴那輛車，而是集中注意力，看看是否更前方有障礙物或者事故放生，做出相應(yīng)的反應(yīng)。

2. 字符串拷貝溢出

這種情況應(yīng)該是最常見了，我們來看一看樣例程序：

#include 《iostream》#define BUFER_SIZE_STR_1 5#define BUFER_SIZE_STR_2 8class DemoClass

{public：

void DoSomething（）

{

strcpy（m_str1， “Hi Coder！”）;

std：：cout 《《 m_str1 《《 std：：endl;

std：：cout 《《 m_str2 《《 std：：endl;

}

private：

char m_str1［BUFER_SIZE_STR_1］ = { 0 };

char m_str2［BUFER_SIZE_STR_2］ = { 0 };

};

int main（）

{

DemoClass testObj;

testObj.DoSomething（）;

return 0;

}

這種情況下肉眼可以分析的，輸出結(jié)果為：

在m_str1的空間為5，但是Hi Coder！包含是10個字符，在調(diào)用strcpy（m_str1， “Hi Coder！”）;的時候超過了m_str1的空間，于是覆蓋了m_str2的內(nèi)存，從而導(dǎo)致內(nèi)存破壞。內(nèi)存溢出這種尤其字符串溢出，程序崩潰可能是小事兒，如果是一個廣為流傳的軟件，那么就很有可能會被黑客所利用。

這種字符串場景如何分析呢，如果程序崩潰了，可以收集Dump先看看被覆蓋的地方是什么樣的字符串，然后聯(lián)想看看自己的程序哪里有可能對這個字符串的操作，從而找到原因。別小看這種方法，簡單粗暴很有用，曾經(jīng)就用這種方式分析過Linux驅(qū)動模塊的內(nèi)存泄露問題。

那如果還找不到問題呢？如果問題還能重現(xiàn)，那還是有調(diào)試手法的，下一節(jié)將會進行講解。

當(dāng)然最差最差的還是不要放棄代碼審查。尤其在這個內(nèi)存被破壞的附近的邏輯。對于這種場景的建議，比較簡單就是使用微軟安全函數(shù)strcpy_s，注意這里雖然列出了返回值errno_t不過對于微軟的實現(xiàn)來說，如果是目標(biāo)內(nèi)存空間不夠的情況下，在Relase版本下會調(diào)用TerminateProcess， 并且要注意的是這個時候抓Dump有時候并不是完整的Dump。

至于微軟為什么要這樣做，有可能是安全的考慮比崩潰優(yōu)先級更高，于是在內(nèi)存溢出不夠的時候，直接讓程序結(jié)束。

errno_t strcpy_s（ char *dest， rsize_t dest_size， const char *src）;

3. 隨機性的內(nèi)存被修改

這一個一聽都快崩潰了，C++的坑能不能少一點呢。但是確實是會有各種各樣的場景讓你落入坑內(nèi)。上一節(jié)的程序我稍作修改：

#include 《iostream》#define BUFER_SIZE_STR_1 5#define BUFER_SIZE_STR_2 8class DemoClass

{public：

void DoSomething（）

{

strcpy_s（m_str2， BUFER_SIZE_STR_2， “Coder”）;

strcpy_s（m_str1， BUFER_SIZE_STR_1， “Test”）;

//Notice this line：

m_str1［BUFER_SIZE_STR_2 - 1］ = ‘’;

std：：cout 《《 m_str1 《《 std：：endl;

std：：cout 《《 m_str2 《《 std：：endl;

}

private：

char m_str1［BUFER_SIZE_STR_1］ = { 0 };

char m_str2［BUFER_SIZE_STR_2］ = { 0 };

};

int main（）

{

DemoClass testObj;

testObj.DoSomething（）;

return 0;

}

程序本意是m_str2賦值為Coder， m_str1賦值為Test， 在編程中很多字符串拷貝或者操作中有些是在字符串末尾補有的可能不補， 而在本例中實際上strcpy_s會自動補0，但是有的程序員防止萬一，字符串靠背后，在數(shù)組的最后一位設(shè)置為’’。這種有時候就變成了好心辦壞事。

比如這里的m_str1［BUFER_SIZE_STR_2 - 1］ = ‘’; ，大家注意到?jīng)]，這里應(yīng)該改寫為m_str1［BUFER_SIZE_STR_1 - 1］ = ‘’; ，也就是說程序員可能拷貝代碼或者不小心寫錯了BUFER_SIZE_STR_2和BUFER_SIZE_STR_1因為兩者宏差不多。只要是人寫代碼，就有可能會犯這種錯誤。這個程序的輸出變?yōu)椋?/p>

這個程序是比較簡單，一目了然，但是在大型程序中呢，這個數(shù)組的位置跳躍的訪問到了其他變量的位置，你首先得判斷這個被跳躍式修改的變量，是不是程序本意造成的，因為混合了這么多的猜想，可能會導(dǎo)致分析變的異常復(fù)雜。那么有什么好的方法嗎？只要程序能偶爾重現(xiàn)這個問題，那就是有方法的。

通過Windbg調(diào)試命令ba可以在指定的內(nèi)存地址做操作的時候進入斷點。假設(shè)目前已經(jīng)知道m(xù)_str2的第四個字符，總是被某個地方誤寫，那么我們可以在這個地址處設(shè)置一個ba命令： 當(dāng)寫的這個內(nèi)存地址的時候進入斷點。不過這樣還是有個問題，那就是程序中有可能有很多次對這塊內(nèi)存的寫操作，有時候是正常的寫操作，如果一直進入斷點，人工分析將會非常累，不現(xiàn)實。

這個時候有個方法，同時也是一個workaround，就是當(dāng)你還沒找到程序出錯的根本原因的時候在被誤踩的內(nèi)存前面加上一個足夠大的不使用的空間。比如下面的代碼， m_str2總是被誤寫，于是在m_str2的前面加上一個100個字節(jié)的不使用的內(nèi)存m_strUnused（因為一般程序內(nèi)存溢出是上溢，當(dāng)然也可以在m_str2的后面同樣加上）。

這樣我們被踩的內(nèi)存就很容易落在m_strUnused空間里面了，這個時候我們在其空間里設(shè)置寫內(nèi)存操作的斷點，就容易捕獲到問題所在了。

#include 《iostream》#define BUFER_SIZE_STR_1 5#define BUFER_SIZE_STR_2 8#define BUFFER_SIZE_UNUSED 100class DemoClass

{public：

void DoSomething（）

{

strcpy_s（m_str2， BUFER_SIZE_STR_2， “Coder”）;

strcpy_s（m_str1， BUFER_SIZE_STR_1， “Test”）;

//Notice this line：

m_str1［BUFER_SIZE_STR_2 - 1］ = ‘’;

std：：cout 《《 m_str1 《《 std：：endl;

std：：cout 《《 m_str2 《《 std：：endl;

}

private：

char m_str1［BUFER_SIZE_STR_1］ = { 0 };

char m_strUnused［BUFFER_SIZE_UNUSED］ = { 0 };

char m_str2［BUFER_SIZE_STR_2］ = { 0 };

};

int main（）

{

DemoClass testObj;

testObj.DoSomething（）;

return 0;

}

下面完整的展示一下分析過程：

第一步 用Windbg啟動（有的情況下可能是Attach，根據(jù)情況而定）到調(diào)試進程，設(shè)置main的斷點

0:000》 bp ObjectMemberBufferOverFllow！main

*** WARNING： Unable to verify checksum for ObjectMemberBufferOverFllow.exe

0:000》 g

Breakpoint 0 hit

eax=010964c0 ebx=00e66000 ecx=00000000 edx=00000000 esi=75aae0b0 edi=0109b390

eip=003a1700 esp=00defa00 ebp=00defa44 iopl=0 nv up ei pl nz na pe nc

cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206

ObjectMemberBufferOverFllow！main：

003a1700 55 push ebp

第二步 使用p命令單步執(zhí)行代碼到testObj.DoSomething（）;

第三步 找到testObj的地址為00def984

0:000》 dv /t /v

00def984 class DemoClass testObj = class DemoClass

第四步 設(shè)置斷點到testObj相對偏移的位置，這個位置即&m_str1+BUFER_SIZE_STR_2 - 1 = &m_str1+7。并且繼續(xù)執(zhí)行代碼：

0:000》 ba w1 00def984+7

0:000》 g

第五步 你會發(fā)現(xiàn)程序運行進入斷點，這個時候查看對應(yīng)的函數(shù)調(diào)用棧即可。這個斷點不一定在一個非常精確的位置，但是當(dāng)你按照函數(shù)調(diào)用棧去閱讀附近的代碼，便比較容易找出問題所在了。

0:000》 k

# ChildEBP RetAddr

00 00def97c 003a1720 ObjectMemberBufferOverFllow！DemoClass：：DoSomething+0x41 ［。..。..strcpybufferoverflow.cpp @ 16］

01 00def9fc 003a1906 ObjectMemberBufferOverFllow！main+0x20 ［。..。..strcpybufferoverflow.cpp @ 30］

02 （Inline） -------- ObjectMemberBufferOverFllow！invoke_main+0x1c ［d:agent\_work3ssrcvctoolscrtvcstartupsrcstartupexe_common.inl @ 78］

03 00defa44 75818494 ObjectMemberBufferOverFllow！__scrt_common_main_seh+0xfa ［d:agent\_work3ssrcvctoolscrtvcstartupsrcstartupexe_common.inl @ 288］

04 00defa58 770a40e8 KERNEL32！BaseThreadInitThunk+0x24

05 00defaa0 770a40b8 ntdll！__RtlUserThreadStart+0x2f

06 00defab0 00000000 ntdll！_RtlUserThreadStart+0x1b

總結(jié)

以上對三種內(nèi)存破壞場景做了分析，在實際應(yīng)用中將會變的更加復(fù)雜。在寫代碼的時候要注意避開其中的坑，有個叫做墨菲定律，你感覺可能會出問題的地方，那它一定會在某個時刻出現(xiàn)，當(dāng)你對某個地方有所疑慮的時候一定要多加考慮，否則這個坑可能查找的時間，比寫代碼的時間要長的許多，更可怕的是可能會帶來意想不到的后果。同樣的分析問題要保持足夠的耐心，相信真相總會出現(xiàn)，這樣的底氣也是來自于自己平時不斷的學(xué)習(xí)和實踐。

內(nèi)存破壞問題不區(qū)分棧上還是堆上，我們在產(chǎn)品中離不開使用堆開間，而且由多個模塊核心功能模塊組成，而這些模塊通常是公用一個進程默認堆的。所以也有人推薦在這些關(guān)鍵模塊中，各自創(chuàng)建一個獨立的堆，從而降低一個堆內(nèi)存的使用對另一個堆中內(nèi)存的影響。雖然不是完全隔離，但是也是一個聊勝于無的操作了。

責(zé)任編輯：haq