成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

從進(jìn)程棧內(nèi)存底層原理到Segmentation fault報(bào)錯(cuò)

開發(fā) 前端
堆棧的物理內(nèi)存是什么時(shí)候分配的?進(jìn)程在加載的時(shí)候只是會(huì)給新進(jìn)程的棧內(nèi)存分配一段地址空間范圍。而真正的物理內(nèi)存是等到訪問的時(shí)候觸發(fā)缺頁中斷,再?gòu)幕锇橄到y(tǒng)中申請(qǐng)的。

大家好,我是飛哥!

棧是編程中使用內(nèi)存最簡(jiǎn)單的方式。例如,下面的簡(jiǎn)單代碼中的局部變量 n 就是在堆棧中分配內(nèi)存的。

#include <stdio.h>
void main()
{
int n = 0;
printf("0x%x\n",&v);
}

那么我有幾個(gè)問題想問問大家,看看大家對(duì)于堆棧內(nèi)存是否真的了解。

  • 堆棧的物理內(nèi)存是什么時(shí)候分配的?
  • 堆棧的大小限制是多大?這個(gè)限制可以調(diào)整嗎?
  • 當(dāng)堆棧發(fā)生溢出后應(yīng)用程序會(huì)發(fā)生什么?

如果你對(duì)以上問題還理解不是特別深刻,飛哥今天來帶你好好修煉進(jìn)程堆棧內(nèi)存這塊的內(nèi)功!

一、進(jìn)程堆棧的初始化

前面我們?cè)凇赌銓懙拇a是如何跑起來的?》這篇文章中介紹了進(jìn)程的啟動(dòng)過程。進(jìn)程啟動(dòng)調(diào)用 exec 加載可執(zhí)行文件過程的時(shí)候,會(huì)給進(jìn)程棧申請(qǐng)一個(gè) 4 KB 的初始內(nèi)存。我們今天來專門抽取并看一下這段邏輯。

加載系統(tǒng)調(diào)用 execve 依次調(diào)用 do_execve、do_execve_common 來完成實(shí)際的可執(zhí)行程序加載。

//file:fs/exec.c
static int do_execve_common(const char *filename, ...)
{
bprm_mm_init(bprm);
...
}

在 bprm_mm_init 中會(huì)申請(qǐng)一個(gè)全新的地址空間 mm_struct 對(duì)象,準(zhǔn)備留著給新進(jìn)程使用。

//file:fs/exec.c
static int bprm_mm_init(struct linux_binprm *bprm)
{
//申請(qǐng)個(gè)全新的地址空間 mm_struct 對(duì)象
bprm->mm = mm = mm_alloc();
__bprm_mm_init(bprm);
}

還會(huì)給新進(jìn)程的棧申請(qǐng)一頁大小的虛擬內(nèi)存空間,作為給新進(jìn)程準(zhǔn)備的棧內(nèi)存。申請(qǐng)完后把棧的指針保存到 bprm->p 中記錄起來。

//file:fs/exec.c
static int __bprm_mm_init(struct linux_binprm *bprm)
{
bprm->vma = vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
vma->vm_end = STACK_TOP_MAX;
vma->vm_start = vma->vm_end - PAGE_SIZE;
...

bprm->p = vma->vm_end - sizeof(void *);
}

我們平時(shí)所說的進(jìn)程虛擬地址空間在 Linux 是通過一個(gè)個(gè)的 vm_area_struct 對(duì)象來表示的。

圖片

每一個(gè) vm_area_struct(就是上面 __bprm_mm_init 函數(shù)中的 vma)對(duì)象表示進(jìn)程虛擬地址空間里的一段范圍,其 vm_start 和 vm_end 表示啟用的虛擬地址范圍的開始和結(jié)束。

//file:include/linux/mm_types.h
struct vm_area_struct {
unsigned long vm_start;
unsigned long vm_end;
...
}

要注意的是這只是地址范圍,而不是真正的物理內(nèi)存分配。

在上面 __bprm_mm_init 函數(shù)中通過 kmem_cache_zalloc 申請(qǐng)了一個(gè) vma 內(nèi)核對(duì)象。vm_end 指向了 STACK_TOP_MAX(地址空間的頂部附近的位置),vm_start 和 vm_end 之間留了一個(gè) Page 大小。也就是說默認(rèn)給棧準(zhǔn)備了 4KB 的大小。最后把棧的指針記錄到 bprm->p 中。

圖片

接下來進(jìn)程加載過程會(huì)使用 load_elf_binary 真正開始加載可執(zhí)行二進(jìn)制程序。在加載時(shí),會(huì)把前面準(zhǔn)備的進(jìn)程棧的地址空間指針設(shè)置到了新進(jìn)程 mm 對(duì)象上。

//file:fs/binfmt_elf.c
static int load_elf_binary(struct linux_binprm *bprm)
{ //ELF 文件頭解析
//Program Header 讀取
//清空父進(jìn)程繼承來的資源
retval = flush_old_exec(bprm);
...

current->mm->start_stack = bprm->p;
}

圖片

這樣新進(jìn)程將來就可以使用棧進(jìn)行函數(shù)調(diào)用,以及局部變量的申請(qǐng)了。

前面我們說了,這里只是給棧申請(qǐng)了地址空間對(duì)象,并沒有真正申請(qǐng)物理內(nèi)存。我們接著再來看一下,物理內(nèi)存頁究竟是什么時(shí)候分配的。

二、物理頁的申請(qǐng)

當(dāng)進(jìn)程在運(yùn)行的過程中在棧上開始分配和訪問變量的時(shí)候,如果物理頁還沒有分配,會(huì)觸發(fā)缺頁中斷。在缺頁中斷種來真正地分配物理內(nèi)存。

為了避免篇幅過長(zhǎng),觸發(fā)缺頁中斷的過程就先不展開了。我們直接看一下缺頁中斷的核心處理入口 __do_page_fault,它位于 arch/x86/mm/fault.c 文件下。

//file:arch/x86/mm/fault.c
static void __kprobes
__do_page_fault(struct pt_regs *regs, unsigned long error_code)
{
...
//根據(jù)新的 address 查找對(duì)應(yīng)的 vma
vma = find_vma(mm, address);

//如果找到的 vma 的開始地址比 address 小
//那么就不調(diào)用expand_stack了,直接調(diào)用
if (likely(vma->vm_start <= address))
goto good_area;
...
if (unlikely(expand_stack(vma, address))) {
bad_area(regs, error_code, address);
return;
}
good_area:
//調(diào)用handle_mm_fault來完成真正的內(nèi)存申請(qǐng)
fault = handle_mm_fault(mm, vma, address, flags);

}

當(dāng)訪問棧上變量的內(nèi)存的時(shí)候,首先會(huì)調(diào)用 find_vma 根據(jù)變量地址 address 找到其所在的 vma 對(duì)象。接下來調(diào)用的 if (vma->vm_start <= address) 是在判斷地址空間還夠不夠用。

圖片

    

如果棧內(nèi)存 vma 的 start 比要訪問的 address 小,則證明地址空間夠用,只需要分配物理內(nèi)存頁就行了。如果棧內(nèi)存 vma 的 start 比要訪問的 address 大,則需要調(diào)用 expand_stack 先擴(kuò)展一下棧的虛擬地址空間 vma。擴(kuò)展虛擬地址空間的具體細(xì)節(jié)我們?cè)诘谌?jié)再講。

這里先假設(shè)要訪問的變量地址 address 處于棧內(nèi)存 vma 對(duì)象的 vm_start 和 vm_end 之間。那么缺頁中斷處理就會(huì)跳轉(zhuǎn)到 good_area 處運(yùn)行。在這里調(diào)用 handle_mm_fault 來完成真正物理內(nèi)存的申請(qǐng)。

//file:mm/memory.c
int handle_mm_fault(struct mm_struct *mm, struct vm_area_struct *vma,
unsigned long address, unsigned int flags)
{
...

//依次查看每一級(jí)頁表項(xiàng)
pgd = pgd_offset(mm, address);
pud = pud_alloc(mm, pgd, address);
pmd = pmd_alloc(mm, pud, address);
pte = pte_offset_map(pmd, address);

return handle_pte_fault(mm, vma, address, pte, pmd, flags);
}

Linux 是用四級(jí)頁表來管理虛擬地址空間到物理內(nèi)存之間的映射管理的。所以在實(shí)際申請(qǐng)物理頁面之前,需要先 check 一遍需要的每一級(jí)頁表項(xiàng)是否存在,不存在的話需要申請(qǐng)。

為了好區(qū)分,Linux 還給每一級(jí)頁表都起了一個(gè)名字。

  • 一級(jí)頁表:Page Global Dir,簡(jiǎn)稱 pgd
  • 二級(jí)頁表:Page Upper Dir,簡(jiǎn)稱 pud
  • 三級(jí)頁表:Page Mid Dir,簡(jiǎn)稱 pmd
  • 四級(jí)頁表:Page Table,簡(jiǎn)稱 pte

看一下下面這個(gè)圖就比較好理解了

圖片

//file:mm/memory.c
int handle_pte_fault(struct mm_struct *mm,
struct vm_area_struct *vma, unsigned long address,
pte_t *pte, pmd_t *pmd, unsigned int flags)
{
...

//匿名映射頁處理
return do_anonymous_page(mm, vma, address,
pte, pmd, flags);
}

在 handle_pte_fault 會(huì)處理很多種的內(nèi)存缺頁處理,比如文件映射缺頁處理、swap缺頁處理、寫時(shí)復(fù)制缺頁處理、匿名映射頁處理等等幾種情況。我們今天討論的主題是棧內(nèi)存,這個(gè)對(duì)應(yīng)的是匿名映射頁處理,會(huì)進(jìn)入到 do_anonymous_page 函數(shù)中。

//file:mm/memory.c
static int do_anonymous_page(struct mm_struct *mm, struct vm_area_struct *vma,
unsigned long address, pte_t *page_table, pmd_t *pmd,
unsigned int flags)
{
// 分配可移動(dòng)的匿名頁面,底層通過 alloc_page
page = alloc_zeroed_user_highpage_movable(vma, address);
...
}

在 do_anonymous_page 調(diào)用 alloc_zeroed_user_highpage_movable 分配一個(gè)可移動(dòng)的匿名物理頁出來。在底層會(huì)調(diào)用到伙伴系統(tǒng)的 alloc_pages 進(jìn)行實(shí)際物理頁面的分配。

內(nèi)核是用伙伴系統(tǒng)來管理所有的物理內(nèi)存頁的。其它模塊需要物理頁的時(shí)候都會(huì)調(diào)用伙伴系統(tǒng)對(duì)外提供的函數(shù)來申請(qǐng)物理內(nèi)存。

圖片

關(guān)于伙伴系統(tǒng)我們之前在內(nèi)核內(nèi)存管理 這篇文章中詳細(xì)介紹過,感興趣的同學(xué)可以移步到該文中詳細(xì)了解。

到了這里,開篇的問題一就有答案了,堆棧的物理內(nèi)存是什么時(shí)候分配的?進(jìn)程在加載的時(shí)候只是會(huì)給新進(jìn)程的棧內(nèi)存分配一段地址空間范圍。而真正的物理內(nèi)存是等到訪問的時(shí)候觸發(fā)缺頁中斷,再?gòu)幕锇橄到y(tǒng)中申請(qǐng)的。

三、棧的自動(dòng)增長(zhǎng)

前面我們看到了,進(jìn)程在被加載啟動(dòng)的時(shí)候,棧內(nèi)存默認(rèn)只分配了 4 KB 的空間。那么隨著程序的運(yùn)行,當(dāng)棧中保存的調(diào)用鏈,局部變量越來越多的時(shí)候,必然會(huì)超過 4 KB。

我回頭看下缺頁處理函數(shù) __do_page_fault。如果棧內(nèi)存 vma 的 start 比要訪問的 address 大,則需要調(diào)用 expand_stack 先擴(kuò)展一下棧的虛擬地址空間 vma。

圖片

回顧 __do_page_fault 源碼,看到擴(kuò)充棧空間的是由 expand_stack 函數(shù)來完成的。

//file:arch/x86/mm/fault.c
static void __kprobes
__do_page_fault(struct pt_regs *regs, unsigned long error_code)
{
...
if (likely(vma->vm_start <= address))
goto good_area;

//如果棧 vma 的開始地址比 address 大,需要擴(kuò)大棧
if (unlikely(expand_stack(vma, address))) {
bad_area(regs, error_code, address);
return;
}
good_area:
...
}

我們來看下 expand_stack 的內(nèi)部細(xì)節(jié)。

其實(shí)在 Linux 棧地址空間增長(zhǎng)是分兩種方向的,一種是從高地址往低地址增長(zhǎng),一種是反過來。大部分情況都是由高往低增長(zhǎng)的。本文只以向下增長(zhǎng)為例。

//file:mm/mmap.c
int expand_stack(struct vm_area_struct *vma, unsigned long address)
{
...
return expand_downwards(vma, address);
}

int expand_downwards(struct vm_area_struct *vma, unsigned long address)
{
...
//計(jì)算棧擴(kuò)大后的最后大小
size = vma->vm_end - address;

//計(jì)算需要擴(kuò)充幾個(gè)頁面
grow = (vma->vm_start - address) >> PAGE_SHIFT;

//判斷是否允許擴(kuò)充
acct_stack_growth(vma, size, grow);

//如果允許則開始擴(kuò)充
vma->vm_start = address;

return ...
}

在 expand_downwards 中先進(jìn)行了幾個(gè)計(jì)算。

  • 計(jì)算出新的堆棧大小。計(jì)算公式是 size = vma->vm_end - address;
  • 計(jì)算需要增長(zhǎng)的頁數(shù)。計(jì)算公式是 grow = (vma->vm_start - address) >> PAGE_SHIFT;

然后會(huì)判斷此次棧空間是否被允許擴(kuò)充, 判斷是在 acct_stack_growth 中完成的。如果允許擴(kuò)展,則簡(jiǎn)單修改一下 vma->vm_start 就可以了!

圖片

我們?cè)賮砜?acct_stack_growth 都進(jìn)行了哪些限制判斷。

//file:mm/mmap.c
static int acct_stack_growth(struct vm_area_struct *vma, unsigned long size, unsigned long grow)
{
...
//檢查地址空間是否超出限制
if (!may_expand_vm(mm, grow))
return -ENOMEM;

//檢查是否超出棧的大小限制
if (size > ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur))
return -ENOMEM;
...
return 0;
}

在 acct_stack_growth 中只是進(jìn)行一系列的判斷。may_expand_vm? 判斷的是增長(zhǎng)完這幾個(gè)頁后是否超出整體虛擬地址空間大小的限制。rlim[RLIMIT_STACK].rlim_cur 中記錄的是棧空間大小的限制。這些限制都可以通過 ulimit 命令查看到。

# ulimit -a
......
max memory size (kbytes, -m) unlimited
stack size (kbytes, -s) 8192
virtual memory (kbytes, -v) unlimited

上面的這個(gè)輸出表示虛擬地址空間大小沒有限制,棧空間的限制是 8 MB。如果進(jìn)程棧大小超過了這個(gè)限制,會(huì)返回 -ENOMEM。如果覺得系統(tǒng)默認(rèn)的大小不合適可以通過 ulimit 命令修改。

# ulimit -s 10240
# ulimit -a
stack size (kbytes, -s) 10240

到這里開篇的第二個(gè)問題也有答案了,堆棧的大小限制是多大?這個(gè)限制可以調(diào)整嗎?進(jìn)程堆棧大小的限制在每個(gè)機(jī)器上都是不一樣的,可以通過 ulimit 命令來查看,也同樣可以使用該命令修改。

至于開篇的問題3,當(dāng)堆棧發(fā)生溢出后應(yīng)用程序會(huì)發(fā)生什么?寫個(gè)簡(jiǎn)單的無限遞歸調(diào)用就知道了,估計(jì)你也遇到過。報(bào)錯(cuò)結(jié)果就是

'Segmentation fault (core dumped)

本文總結(jié)

來總結(jié)下本文的內(nèi)容,本文討論了進(jìn)程棧內(nèi)存的工作原理。

第一,進(jìn)程在加載的時(shí)候給進(jìn)程棧申請(qǐng)了一塊虛擬地址空間 vma 內(nèi)核對(duì)象。vm_start 和 vm_end 之間留了一個(gè) Page ,也就是說默認(rèn)給棧準(zhǔn)備了 4KB 的空間。第二,當(dāng)進(jìn)程在運(yùn)行的過程中在棧上開始分配和訪問變量的時(shí)候,如果物理頁還沒有分配,會(huì)觸發(fā)缺頁中斷。在缺頁中斷中調(diào)用內(nèi)核的伙伴系統(tǒng)真正地分配物理內(nèi)存。第三,當(dāng)棧中的存儲(chǔ)超過 4KB 的時(shí)候會(huì)自動(dòng)進(jìn)行擴(kuò)大。不過大小要受到限制,其大小限制可以通過 ?ulimit -s來查看和設(shè)置。

圖片

注意,今天我們討論的都是進(jìn)程棧。線程棧和進(jìn)程棧有些不一樣。等后面有空我們?cè)賳为?dú)看線程棧。

在回顧和總結(jié)下開篇我們拋出的三個(gè)問題: 

問題一:堆棧的物理內(nèi)存是什么時(shí)候分配的?進(jìn)程在加載的時(shí)候只是會(huì)給新進(jìn)程的棧內(nèi)存分配一段地址空間范圍。而真正的物理內(nèi)存是等到訪問的時(shí)候觸發(fā)缺頁中斷,再?gòu)幕锇橄到y(tǒng)中申請(qǐng)的。 

問題二:堆棧的大小限制是多大?這個(gè)限制可以調(diào)整嗎?進(jìn)程堆棧大小的限制在每個(gè)機(jī)器上都是不一樣的,可以通過 ulimit 命令來查看,也同樣可以使用該命令修改。 

問題3:當(dāng)堆棧發(fā)生溢出后應(yīng)用程序會(huì)發(fā)生什么?當(dāng)堆棧溢出的時(shí)候,我們會(huì)收到報(bào)錯(cuò) “Segmentation fault (core dumped)”

最后,拋個(gè)問題大家一起思考吧。你覺得內(nèi)核為什么要對(duì)進(jìn)程棧的地址空間進(jìn)行限制呢?

責(zé)任編輯:武曉燕 來源: 開發(fā)內(nèi)功修煉
相關(guān)推薦

2021-05-11 07:51:30

React ref 前端

2025-04-07 03:02:00

電腦內(nèi)存數(shù)據(jù)

2024-07-07 21:49:22

2018-05-17 15:18:48

Logistic回歸算法機(jī)器學(xué)習(xí)

2025-04-02 07:29:14

2024-12-17 08:04:04

2021-01-18 09:42:41

C語言底層技巧

2024-03-27 10:14:48

2010-06-29 14:20:52

2020-04-28 22:12:30

Nginx正向代理反向代理

2022-02-28 10:05:12

組件化架構(gòu)設(shè)計(jì)從原組件化模塊化

2021-07-20 10:26:53

源碼底層ArrayList

2023-08-03 08:03:05

2025-04-03 00:03:00

數(shù)據(jù)內(nèi)存網(wǎng)絡(luò)

2025-05-28 08:45:00

2025-03-14 12:30:00

Redis RDBRedis數(shù)據(jù)庫(kù)

2017-07-06 11:34:17

神經(jīng)形態(tài)計(jì)算人工智能突觸

2017-06-16 16:58:54

機(jī)器學(xué)習(xí)神經(jīng)形態(tài)架構(gòu)

2025-03-03 00:00:00

Chrome工具前端

2022-02-14 21:17:21

RPC框架協(xié)議
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)

主站蜘蛛池模板: 国产免费一级片 | 亚洲国产精品久久 | 精品国产一区二区三区在线观看 | 在线观看黄色 | 黄 色 毛片免费 | 五月天婷婷综合 | 午夜在线免费观看 | 亚洲精品久久久久中文字幕欢迎你 | 久久亚洲精品国产精品紫薇 | 免费在线性爱视频 | 毛片久久久 | a久久 | 国产日产欧产精品精品推荐蛮挑 | 日韩综合在线 | 日韩欧美在线一区 | 国产电影一区二区在线观看 | 精品一区二区三区中文字幕 | 亚洲欧洲在线看 | 91小视频在线 | 一区二区三区欧美 | 久久久精品一区二区三区四季av | 日本电影韩国电影免费观看 | 欧美日韩一区精品 | 日中文字幕在线 | 亚洲精品视频一区二区三区 | 亚洲国产成人精品女人久久久 | 在线一区二区观看 | 玖玖在线精品 | 国产日韩一区二区三免费高清 | 欧美性精品 | 国产黄色网 | 国产激情一区二区三区 | 国内自拍视频在线观看 | 色综合天天天天做夜夜夜夜做 | 久久久一二三 | 亚洲一区毛片 | 99免费在线视频 | 不卡视频在线 | 亚洲综合大片69999 | 黄色激情毛片 | 欧美日韩高清 |