對許多的嵌入式開發者而言,堆棧似乎是一股相當神秘的力量。當奇怪的事情開始發生,工程師終於被難倒了,他們開始思考,也許堆棧中發生了什麼事。結果是盲目地調整堆棧的大小和位置等等。但該錯誤往往是與堆棧無關的,但怎能如此確定?畢竟,有多少工程師真的實際執行過最壞情況下的堆棧大小分析?
堆棧大小是在編譯時就靜態分配好的,但堆棧是以動態的方式使用的。隨著代碼的執行,應用程序需要的變量、返回的地址和其它信息被不斷存儲在堆棧中。這種機制導致堆棧在其分配的內存中不斷增長。然而,這種增長有時會超出編譯時確定的容量極限,導致堆棧破壞相鄰內存區域的數據。
絕對確保堆棧正常工作的一種方法是實現堆棧監視器,將它作為系統“保健”代碼的一部分(有多少工程師會這樣做?)。堆棧監視器會在堆棧和“其它”內存區域之間創建一個緩衝區域,並填充已知的位模式。然後監視器會不斷的監視圖案是否有任何變化。如果該位模式發生了改變,那就意味著堆棧增長得太大了,即將要把系統推向黑暗地獄!此時監視器可以記錄事件的發生、系統狀態以及任何其它有用的數據,供日後用於問題的診斷。
大多數實時操作系統(RTOS)或實現了內存保護單元(MPU)的微控制器系統中都提供有堆棧監視器。可怕的是,這些功能默認都是關閉狀態,或者經常被開發人員有意關閉。在網絡上快速搜尋一下可以發現,很多人建議關閉實時操作系統中的堆棧監視器以節省56字節的閃存空間等等,這可是得不償失的做法!