從進程棧內存底層原理到Segmentation fault報錯
大家好,我是飛哥!
棧是編程中使用內存最簡單的方式。例如,下面的簡單代碼中的局部變量 n 就是在堆棧中分配內存的。
那么我有幾個問題想問問大家,看看大家對于堆棧內存是否真的了解。
- 堆棧的物理內存是什么時候分配的?
- 堆棧的大小限制是多大?這個限制可以調整嗎?
- 當堆棧發生溢出后應用程序會發生什么?
如果你對以上問題還理解不是特別深刻,飛哥今天來帶你好好修煉進程堆棧內存這塊的內功!
一、進程堆棧的初始化
前面我們在《你寫的代碼是如何跑起來的?》這篇文章中介紹了進程的啟動過程。進程啟動調用 exec 加載可執行文件過程的時候,會給進程棧申請一個 4 KB 的初始內存。我們今天來專門抽取并看一下這段邏輯。
加載系統調用 execve 依次調用 do_execve、do_execve_common 來完成實際的可執行程序加載。
在 bprm_mm_init 中會申請一個全新的地址空間 mm_struct 對象,準備留著給新進程使用。
還會給新進程的棧申請一頁大小的虛擬內存空間,作為給新進程準備的棧內存。申請完后把棧的指針保存到 bprm->p 中記錄起來。
我們平時所說的進程虛擬地址空間在 Linux 是通過一個個的 vm_area_struct 對象來表示的。
每一個 vm_area_struct(就是上面 __bprm_mm_init 函數中的 vma)對象表示進程虛擬地址空間里的一段范圍,其 vm_start 和 vm_end 表示啟用的虛擬地址范圍的開始和結束。
要注意的是這只是地址范圍,而不是真正的物理內存分配。
在上面 __bprm_mm_init 函數中通過 kmem_cache_zalloc 申請了一個 vma 內核對象。vm_end 指向了 STACK_TOP_MAX(地址空間的頂部附近的位置),vm_start 和 vm_end 之間留了一個 Page 大小。也就是說默認給棧準備了 4KB 的大小。最后把棧的指針記錄到 bprm->p 中。
接下來進程加載過程會使用 load_elf_binary 真正開始加載可執行二進制程序。在加載時,會把前面準備的進程棧的地址空間指針設置到了新進程 mm 對象上。
這樣新進程將來就可以使用棧進行函數調用,以及局部變量的申請了。
前面我們說了,這里只是給棧申請了地址空間對象,并沒有真正申請物理內存。我們接著再來看一下,物理內存頁究竟是什么時候分配的。
二、物理頁的申請
當進程在運行的過程中在棧上開始分配和訪問變量的時候,如果物理頁還沒有分配,會觸發缺頁中斷。在缺頁中斷種來真正地分配物理內存。
為了避免篇幅過長,觸發缺頁中斷的過程就先不展開了。我們直接看一下缺頁中斷的核心處理入口 __do_page_fault,它位于 arch/x86/mm/fault.c 文件下。
當訪問棧上變量的內存的時候,首先會調用 find_vma 根據變量地址 address 找到其所在的 vma 對象。接下來調用的 if (vma->vm_start <= address) 是在判斷地址空間還夠不夠用。
如果棧內存 vma 的 start 比要訪問的 address 小,則證明地址空間夠用,只需要分配物理內存頁就行了。如果棧內存 vma 的 start 比要訪問的 address 大,則需要調用 expand_stack 先擴展一下棧的虛擬地址空間 vma。擴展虛擬地址空間的具體細節我們在第三節再講。
這里先假設要訪問的變量地址 address 處于棧內存 vma 對象的 vm_start 和 vm_end 之間。那么缺頁中斷處理就會跳轉到 good_area 處運行。在這里調用 handle_mm_fault 來完成真正物理內存的申請。
Linux 是用四級頁表來管理虛擬地址空間到物理內存之間的映射管理的。所以在實際申請物理頁面之前,需要先 check 一遍需要的每一級頁表項是否存在,不存在的話需要申請。
為了好區分,Linux 還給每一級頁表都起了一個名字。
- 一級頁表:Page Global Dir,簡稱 pgd
- 二級頁表:Page Upper Dir,簡稱 pud
- 三級頁表:Page Mid Dir,簡稱 pmd
- 四級頁表:Page Table,簡稱 pte
看一下下面這個圖就比較好理解了
在 handle_pte_fault 會處理很多種的內存缺頁處理,比如文件映射缺頁處理、swap缺頁處理、寫時復制缺頁處理、匿名映射頁處理等等幾種情況。我們今天討論的主題是棧內存,這個對應的是匿名映射頁處理,會進入到 do_anonymous_page 函數中。
在 do_anonymous_page 調用 alloc_zeroed_user_highpage_movable 分配一個可移動的匿名物理頁出來。在底層會調用到伙伴系統的 alloc_pages 進行實際物理頁面的分配。
內核是用伙伴系統來管理所有的物理內存頁的。其它模塊需要物理頁的時候都會調用伙伴系統對外提供的函數來申請物理內存。
關于伙伴系統我們之前在內核內存管理 這篇文章中詳細介紹過,感興趣的同學可以移步到該文中詳細了解。
到了這里,開篇的問題一就有答案了,堆棧的物理內存是什么時候分配的?進程在加載的時候只是會給新進程的棧內存分配一段地址空間范圍。而真正的物理內存是等到訪問的時候觸發缺頁中斷,再從伙伴系統中申請的。
三、棧的自動增長
前面我們看到了,進程在被加載啟動的時候,棧內存默認只分配了 4 KB 的空間。那么隨著程序的運行,當棧中保存的調用鏈,局部變量越來越多的時候,必然會超過 4 KB。
我回頭看下缺頁處理函數 __do_page_fault。如果棧內存 vma 的 start 比要訪問的 address 大,則需要調用 expand_stack 先擴展一下棧的虛擬地址空間 vma。
回顧 __do_page_fault 源碼,看到擴充棧空間的是由 expand_stack 函數來完成的。
我們來看下 expand_stack 的內部細節。
其實在 Linux 棧地址空間增長是分兩種方向的,一種是從高地址往低地址增長,一種是反過來。大部分情況都是由高往低增長的。本文只以向下增長為例。
在 expand_downwards 中先進行了幾個計算。
- 計算出新的堆棧大小。計算公式是 size = vma->vm_end - address;
- 計算需要增長的頁數。計算公式是 grow = (vma->vm_start - address) >> PAGE_SHIFT;
然后會判斷此次棧空間是否被允許擴充, 判斷是在 acct_stack_growth 中完成的。如果允許擴展,則簡單修改一下 vma->vm_start 就可以了!
我們再來看 acct_stack_growth 都進行了哪些限制判斷。
在 acct_stack_growth 中只是進行一系列的判斷。may_expand_vm? 判斷的是增長完這幾個頁后是否超出整體虛擬地址空間大小的限制。rlim[RLIMIT_STACK].rlim_cur 中記錄的是棧空間大小的限制。這些限制都可以通過 ulimit 命令查看到。
上面的這個輸出表示虛擬地址空間大小沒有限制,棧空間的限制是 8 MB。如果進程棧大小超過了這個限制,會返回 -ENOMEM。如果覺得系統默認的大小不合適可以通過 ulimit 命令修改。
到這里開篇的第二個問題也有答案了,堆棧的大小限制是多大?這個限制可以調整嗎?進程堆棧大小的限制在每個機器上都是不一樣的,可以通過 ulimit 命令來查看,也同樣可以使用該命令修改。
至于開篇的問題3,當堆棧發生溢出后應用程序會發生什么?寫個簡單的無限遞歸調用就知道了,估計你也遇到過。報錯結果就是
本文總結
來總結下本文的內容,本文討論了進程棧內存的工作原理。
第一,進程在加載的時候給進程棧申請了一塊虛擬地址空間 vma 內核對象。vm_start 和 vm_end 之間留了一個 Page ,也就是說默認給棧準備了 4KB 的空間。第二,當進程在運行的過程中在棧上開始分配和訪問變量的時候,如果物理頁還沒有分配,會觸發缺頁中斷。在缺頁中斷中調用內核的伙伴系統真正地分配物理內存。第三,當棧中的存儲超過 4KB 的時候會自動進行擴大。不過大小要受到限制,其大小限制可以通過 ?ulimit -s來查看和設置。
注意,今天我們討論的都是進程棧。線程棧和進程棧有些不一樣。等后面有空我們再單獨看線程棧。
在回顧和總結下開篇我們拋出的三個問題:
問題一:堆棧的物理內存是什么時候分配的?進程在加載的時候只是會給新進程的棧內存分配一段地址空間范圍。而真正的物理內存是等到訪問的時候觸發缺頁中斷,再從伙伴系統中申請的。
問題二:堆棧的大小限制是多大?這個限制可以調整嗎?進程堆棧大小的限制在每個機器上都是不一樣的,可以通過 ulimit 命令來查看,也同樣可以使用該命令修改。
問題3:當堆棧發生溢出后應用程序會發生什么?當堆棧溢出的時候,我們會收到報錯 “Segmentation fault (core dumped)”
最后,拋個問題大家一起思考吧。你覺得內核為什么要對進程棧的地址空間進行限制呢?