1、正文部分

1先說(shuō)幾句

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

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

2理一理堆棧溢出

1堆棧名稱(chēng)

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

2圖解堆棧溢出

來(lái)我們首先看一個(gè)函數(shù):

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

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

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

3如何分配堆棧空間大小

1堆棧內(nèi)容

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

局部變量的分配。

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

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

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

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

2計(jì)算最大堆棧空間難題

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

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

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

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

4確定堆棧大小的好辦法

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

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

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

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

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

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

版權(quán)聲明：本文來(lái)源公眾號(hào)最后一個(gè)bug

審核編輯：湯梓紅