1、正文部分

1先說幾句

前些日子bug交流群里的小哥調(diào)試了一個堆棧溢出的bug，動不動數(shù)據(jù)就被篡改了，應(yīng)該也是搞得焦頭爛額，頭皮發(fā)麻！當(dāng)時bug菌看了下，于是拋出了自己的一些調(diào)試經(jīng)驗，一般這樣的問題80%是越界和堆棧溢出造成的，沒想到還真是堆棧溢出。

所以對于一些問題的處理不僅僅是經(jīng)驗的積累，還需要多多交流！堆棧溢出問題bug菌和他算是“老朋友”了，所以非常想讓相關(guān)文章跟大家見面，沒想到這幾天事情頗多，每天回家都沒有太多的精力去更文，但是作為一名有態(tài)度的號主還是要堅持為大家?guī)睃c東西！

2理一理堆棧溢出

1堆棧名稱

認(rèn)識堆棧溢出首先我們要知道什么是" 堆棧 " ? 堆棧從名字上理解似乎是堆和棧的結(jié)合，而我們在數(shù)據(jù)結(jié)構(gòu)中知道堆和棧是兩種不同的數(shù)據(jù)結(jié)構(gòu)，但這里的堆棧指的僅僅是棧，從英文名我們就可以知道 : 堆棧(stack)和堆(heap) , 至于把stack叫做堆棧是有一定的歷史和翻譯原因的，bug菌就不追溯了。 對于棧，在bug菌的往期文章中也有提及，其實就是一種先進后出的數(shù)據(jù)結(jié)構(gòu)；而在CPU層面有著堆棧寄存器，push和pop堆棧操作指令等等都是用于操作棧區(qū)的。 在C語言環(huán)境中棧是為了保存現(xiàn)場的信息，當(dāng)程序需要執(zhí)行函數(shù)調(diào)用，任務(wù)切換等等都會把相應(yīng)的數(shù)據(jù)push到棧中，一旦回到原來函數(shù)和任務(wù)又會pop彈出之前的數(shù)據(jù)繼續(xù)往下執(zhí)行。 但棧是有具體大小的，一旦入棧的數(shù)據(jù)過多，就會導(dǎo)致罪惡的"堆棧溢出"問題。

2圖解堆棧溢出

來我們首先看一個函數(shù):

voidRecvData(void);
{
intCnt;
intBuff[6];
......
dosomething...
}

上圖就不區(qū)分堆棧增長方向了，僅僅只是表述堆棧溢出現(xiàn)象，由于SP_end以外的內(nèi)容未知，一般都由編譯器分配決定，如果編譯器把重要數(shù)據(jù)分配到此區(qū)域，一旦程序訪問到Buff[3]往下的數(shù)據(jù)便會導(dǎo)致數(shù)據(jù)篡改，從而程序發(fā)生一些奇怪的行為，甚至奔潰。

那么很多朋友就會想，直接給這個任務(wù)或者系統(tǒng)分配一個1024或者4096個字節(jié)的堆棧，這總不會造成堆棧溢出了吧！我只想說："你太秀了！"。

3如何分配堆棧空間大小

1堆棧內(nèi)容

盲目的分配過大的堆?？臻g，無非就是對資源的浪費。如果你的項目能夠讓你這樣任性，那你們產(chǎn)品成本估算就真是個形式。所以合理的分配堆棧大小是非常重要的，首先我們得看看堆棧中主要放些什么 ?

局部變量的分配。

函數(shù)調(diào)用嵌套的返回地址等等數(shù)據(jù)的push，這個需要根據(jù)具體的CPU進行函數(shù)調(diào)用約定來進行分析。

函數(shù)的參數(shù)，因為有時候編譯器為了增加執(zhí)行效率會把相關(guān)參數(shù)放在寄存器中傳遞，但是畢竟這樣的寄存器有限，過多的參數(shù)還是會通過堆棧來傳遞。

當(dāng)我們觸發(fā)中斷CPU一般會自動把相應(yīng)的信息壓入堆棧中，從而保存中斷現(xiàn)場。

對于RTOS進行任務(wù)切換、中斷等過程中一般系統(tǒng)僅自動保存了部分寄存器等信息，而為了全面的保存好現(xiàn)場，還需要手動的壓入一些其他的信息，比如stm32中的FPU相關(guān)寄存器信息等。

2計算最大堆?？臻g難題

有了前面堆棧中放了些啥的分析，要確定堆棧的空間大小自然而然的就會想到把一個個加起來算堆棧最大暫用情況，算出該值以后預(yù)留一定的空間就再合適不過了。

現(xiàn)在對于比較強大的IDE，比如keil和IAR，都可以提供計算堆棧占用最大的情況，而對于我們采用函數(shù)指針這樣的間接調(diào)用函數(shù)的方式或者是C嵌入式匯編等等，那IDE也無能為力。

更加可怕的是使用printf這種可變參數(shù)的函數(shù)，其堆棧的占用情況是根據(jù)參數(shù)的多少而動態(tài)變化的，其并不那么容易確定。

當(dāng)然還有最讓bug菌難以忘記的情況 : 遞歸 , 遞歸就是反復(fù)的函數(shù)調(diào)用，那么一系列的返回現(xiàn)場數(shù)據(jù)都會壓入棧中，堆棧占用情況也是未知的，所以在嵌入式中使用遞歸一定要限制遞歸的深度，防止堆棧溢出。

4確定堆棧大小的好辦法

既然正面計算堆棧占用最糟糕的情形如此麻煩，那我們從側(cè)面出擊，那就是我們常用的檢測堆棧使用峰值法，實時的采集和輸出堆棧的使用信息，我們根據(jù)堆棧的最大值*1.5倍的樣子，基本上就可以把堆棧大小確定下來。

像目前的RTOS(如ucos、freertos等)都提供了對應(yīng)的堆棧信息輸出API，比如ucos中的OSTaskStkChk函數(shù) :

typedefstructos_stk_data
{
INT32UOSFree;/*Numberoffreeentriesonthestack*/
INT32UOSUsed;/*Numberofentriesusedonthestack*/
}OS_STK_DATA;
......
INT8UOSTaskStkChk(
INT8Uprio,
OS_STK_DATA*p_stk_data
);

通過調(diào)用該函數(shù)獲得已經(jīng)使用的和沒有使用的堆棧大小，便可以獲得堆棧的使用情況，如:

堆棧占用率 = (OSUsed/(OSUsed + OSFree)) * 100%

從而可以將該參數(shù)輸出作為我們評估每個任務(wù)分配的堆棧是否合適，當(dāng)然你需要讓程序運行足夠長的時間和盡量多的情況，從而獲得最差的情況，再考慮預(yù)留>20%的空間，最終重新調(diào)整每個堆棧大小到合適狀態(tài)。

版權(quán)聲明：本文來源公眾號最后一個bug

審核編輯：湯梓紅