我們知道每個線程初始堆棧的默認空間是1M， 我們可以在VC編譯的Linker項里進行設置，該值會被編譯進最終的PE可執行文件中。線程堆棧內存包括commit部分和reserver部分，我們上面說的1M實際上指reserve部分，系統為了節約內存，并不會把所有reserve的1M都提交物理內存(commit), 所以初始只是提交部分內存。
我們可以隨便找一個程序，通過WinDbg進行驗證：!address -f:stack
BaseAddr EndAddr+1 RgnSize Type State Protect Usage
---------------------------------------------------------------------------------------------
90000 184000 f4000 MEM_PRIVATE MEM_RESERVE Stack [~0; 16d8.13ec]
184000 185000 1000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE|PAGE_GUARD Stack [~0; 16d8.13ec]
185000 190000 b000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE Stack [~0; 16d8.13ec]
可以看到一個線程的堆棧分3部分：0xB000字節的MEM_COMMIT內存，0x1000字節的MEM_COMMIT & PAGE_GUARD內存，還有0xF4000字節的MEM_RESERVE內存，總共是0xB000+0x1000+0xf4000 = 0x100000 = 1M
通過實驗，我們可以看到線程堆棧只提交(commit)了一部分內存，大部分內存是reserve的，現在的問題是堆棧在增長的過程中，它是如何提交(commit)內存的？ 我們知道，我們在函數中申明一個N字節大小的局部變量，它就是在線程的堆棧中申請的空間(實際上只需要ESP-N)就可以了。我們如果觀察過函數的反匯編代碼，會注意到它沒有commit內存相關的代碼。 那么究竟最終它是如何commit那些reserve的內存的呢？
曾經面試被問到這個問題， 因為沒有看過相關的書籍， 沒回答出來...
最近思考這個問題， 終于在張銀奎的<<軟件調試>>里找到了答案：
系統在提交棧空間時會故意多提交一個頁面，稱這個頁面為棧保護頁面（Stack Guard Page）, 這點我們可以在上面WinDbg的實驗中驗證。棧保護頁面具有特殊的PAGE_GUARD屬性，當具有如此屬性的內存頁被訪問時，CPU會產生頁錯誤并開始執行系統的內存管理函數，當內存管理函數檢測到PAGE_GUARD屬性后，會清除對應頁面的PAGE_GUARD屬性，然后調用一個名為MiCheckForUserStackOverflow的系統函數，這個函數會從當前線程的TEB中讀取用戶態棧的基本信息并檢查導致異常的地址，如果導致異常的被訪問地址不屬于?？臻g范圍，則返回STATUS_GUARD_PAGE_VIOLATION，否則MiCheckForUserStackOverflow函數會計算棧中是否還有足夠的剩余空間可以創建一個新的棧保護頁面。如果有，則調用ZwAllocateVirtualMemory從保留的空間中在提交一個具有PAGE_GUARD屬性的內存頁。新的棧保護頁與原來的緊鄰，經過這樣的操作后，棧的保護頁向低地址方向平移了一位，棧的可用空間增大了一個頁面的大小，這便是所謂的?？臻g自動增長。
棧溢出是指當提交的?？臻g再被用完，棧保護頁又被訪問時，系統便會重復以上過程，直到當棧保護頁距離保留空間的最后一個頁面只剩一個頁面的空間時，MiCheckForUserStackOverflow函數會提交倒數第二個頁面，但不再設置PAGE_GUARD屬性，因為最后一個頁面永遠保留不可訪問，所以這時棧增長到它的最大極限，為了讓應用程序知道棧將用完，MiCheckForUserStackOverflow函數返回STATUS_STACK_OVERFLOW，觸發棧溢出異常。
最后感概技術深了可以再深，從C++編譯器到CRT運行庫， 再到操作系統， 從用戶態到內核和驅動， 最后到硬件， 原理背后還有原理， 真正能掌握所有細節的又有幾人呢？
posted on 2014-10-12 22:03
Richard Wei 閱讀(5474)
評論(3) 編輯 收藏 引用 所屬分類:
windbg