真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

成都創(chuàng)新互聯(lián)網(wǎng)站制作重慶分公司

請(qǐng)使勁回答一個(gè)關(guān)于UNIX/Linux自動(dòng)擴(kuò)展stack的問-創(chuàng)新互聯(lián)

有本事就出來,沒本事就當(dāng)鱉!

創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比蘄春網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式蘄春網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們,業(yè)務(wù)覆蓋蘄春地區(qū)。費(fèi)用合理售后完善,十多年實(shí)體公司更值得信賴。

如果讓我回答關(guān)于進(jìn)程棧,線程棧的問題,只要問題不籠統(tǒng),只要問題明確,我會(huì)一五一十地回答,正確率上九成,然而,可悲的是,問題往往他媽的都不是 很明確,因此,游戲到此結(jié)束??!艸。但是如果給我一個(gè)問的機(jī)會(huì),我會(huì)問下面一個(gè)問題,記住,使出你拉屎的勁來回答(該問題足夠糙!不必太當(dāng)回事,重要的東 西在下面-):

UNIX/Linux 的stack在大多數(shù)平臺(tái)是向下擴(kuò)展的(注意,我已經(jīng)告訴他事實(shí)了,我并沒有問...是如何擴(kuò)展的,這是可以背誦下來并朗讀出來的),在一個(gè)執(zhí)行流調(diào)用了 一個(gè)函數(shù)A,而該函數(shù)A在stack上分配了一個(gè)大數(shù)組導(dǎo)致了stack擴(kuò)展(注意,這又是一段陳述,我還沒有給出問題),然后A返回 了,UNIX/Linux理應(yīng)回收調(diào)A里面大數(shù)組分配stack空間-因?yàn)樗僖矝]有用了,但是它并沒有這么做(這里可能是一個(gè)陷阱,真的是UNIX /Linux理應(yīng)這么做卻沒有做,還是說我只是在逗你玩...不確定,但陳述就是如此)。(注意,我的問題來了),請(qǐng)問,UNIX/Linux為什么這么 做????。?!
       凡是回答操作系統(tǒng)這么規(guī)定的之類的答案,一律零分!況且,你能證明我說的一定對(duì)嗎?萬一我是逗你玩呢?操作系統(tǒng)能規(guī)定一個(gè)錯(cuò)的東西嗎?或者我可以繼續(xù)問為 什么這么規(guī)定,直到像我初中的歷史老師被我問到朝我眼角猛打一拳那樣,如果我能找回點(diǎn)賤人所謂的快感,那么來打吧!問題就是這樣,不管這個(gè)問題是一個(gè)偽命 題還是你有自己的想法,能說5分鐘的,我覺得也夠可以了。該題目的答題要求如下:
時(shí)間限制:5分鐘。
作答方式:全口述,不能畫圖,不能打手勢(shì)...語(yǔ)言含糊不清的,表達(dá)能力不好的,算錯(cuò)誤。
答題建議:如果你對(duì)OS虛擬內(nèi)存管理以及Linux的VMA實(shí)現(xiàn)細(xì)節(jié)沒有相當(dāng)深入的理解,請(qǐng)不要猜測(cè)答案。請(qǐng)直接回答“不知道”,然后看完此文。

.................................
5分鐘過去。我要公布一點(diǎn)我的想法了。
      首先,這個(gè)問題在本身看來,有問題。因?yàn)殡m然Linux理應(yīng)這么做,但它:
第一,它不一定能做到;
第二,它根本沒有必要做。

那么論據(jù)是什么?憑什么這樣說?

積極論點(diǎn)

沒必要這樣做。執(zhí)行流還會(huì)調(diào)用別的函數(shù)或者再次調(diào)用A,頻繁回收棧損耗性能;

消極論點(diǎn)

很難或者不能做到。stack操作是處理器控制的,和OS內(nèi)核地址空間管理機(jī)制之間沒有同步機(jī)制,一個(gè)函數(shù)調(diào)用結(jié)束后,CPU自動(dòng)處理stack寄存器的收縮,彈出棧幀,然而它無法通知OS內(nèi)存管理系統(tǒng)去更新進(jìn)程地址空間的映射關(guān)系。

如何處理stack所在地址空間區(qū)域的爭(zhēng)議

stack 會(huì)一直擴(kuò)展到碰到異常的地址B,B可能是一個(gè)readonly的地址或者是一個(gè)保護(hù)空洞,在向下擴(kuò)展stack情況下,如果地址B偏上,會(huì)導(dǎo)致stack 空間變小,如果偏下,一旦函數(shù)局部變量幾乎占滿了stack底到B的空間,mmap雖然也能unmap掉這段區(qū)域然后remap,然而這會(huì)使數(shù)據(jù)混亂,造 成嚴(yán)重問題。

拍腦袋的結(jié)論

mmap或者brk期間,比較stack頂部與esp寄存器,若小于則回收(等于是正常的,大于是不可能的)。

Linux真實(shí)的做法

Linux 沒有判斷什么esp寄存器,Linux的原則很簡(jiǎn)單,只要一個(gè)地址處在一個(gè)vma范圍內(nèi)或者處在stack可擴(kuò)展的范圍內(nèi),且擁有權(quán)限的,它就是可以訪 問,內(nèi)核是不管這個(gè)VMA是屬于stack還是heap或者別的什么,具體由應(yīng)用程序自己控制,也就是說,你完全可以寫一段代碼,把地址空間中所有可以寫 的區(qū)域全部清零,這完全有可能,緩沖區(qū)溢出可能是一種蓄意的破壞,然而程序員偶然的錯(cuò)誤也會(huì)造成破壞,雖然他們大多數(shù)都不知道錯(cuò)誤是如何發(fā)生的。我不想用 文字長(zhǎng)篇大論Linux是如何管理VMA的,你知道這個(gè)應(yīng)該是一個(gè)前提,你必須知道這個(gè)。我用一段代碼以及兩個(gè)圖示來展示Linux系統(tǒng)內(nèi)核是如何管理 stack附近的地址空間映射的,并且在第二張圖中給出,如果你非要蓄意破壞,會(huì)造成什么問題。也就是說,一旦發(fā)生莫名奇妙的錯(cuò)誤,你必須能從細(xì)節(jié)上理解 這個(gè)錯(cuò)誤是如何發(fā)生的。

演示代碼

#include  #include  #include  #include  #include  #define LARGE       70000000 #define PAGESIZE    4096 // 該函數(shù)什么都不做,僅僅為了把stack向下擴(kuò)展 // 請(qǐng)注意用ulimit將stack大小限制去掉,這樣會(huì)更容易說明問題 void call() {     int i;     char a[LARGE];     // 請(qǐng)相信,一定是在中間的賦值中觸發(fā)segfault,因?yàn)閮蛇叺脑匾刺幵趕tack/fixmap vma,     // 要么處在游離的,及其孤獨(dú)的,被fixmap給截?cái)嗔说膙ma中。因此下面的賦值不會(huì)引發(fā)段錯(cuò)誤:     // a[0] = 1;     // a[LARGE-1] = 1;     for (i = 0; i < LARGE; i++) {         a[i] = 1;     }   } int main(int argc, char **argv) {     int i;     char *p_map, *p_base, *p_base2;     printf("%d\ninit state\n", getpid());     // 獲取stack的大致地址,并且PAGESIZE對(duì)齊。     p_base = (char *)&i;     p_base2 = (char *)(((unsigned long)p_base) & ~4095);     // 獲取pagesize對(duì)齊的用來fixmap的地址,該地址起點(diǎn)在當(dāng)前stack的下面。     p_base2 = (char *)((unsigned long)p_base2 - (unsigned long)36*PAGESIZE);     getchar();     // 調(diào)用fixmap,顯然,如果你仔細(xì)在getchar期間分析了/proc/xx/maps文件并且     // 得到了上述的那些magic number,下面的mmap無論如何是會(huì)成功的!     p_map = (char *)mmap((void*)p_base2, PAGESIZE*3, PROT_READ | PROT_WRITE,                          MAP_FIXED |MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);     if (p_map == MAP_FAILED) {         printf("failed 1\n");     } else {         printf("before unmap fixmap around stack\n");         getchar();         // 成功了就釋放掉它,此時(shí)的地址空間恢復(fù)成mmap之前的狀況         munmap(p_map, PAGESIZE*3);     }           printf("after unmap fixmap around stack\n");     getchar();     call();     printf("after extend stack[first]\n");     getchar();     // 依然調(diào)用之前的那個(gè)一模一樣的mmap進(jìn)行fixmap,由于調(diào)用了call,stack     // 空間已經(jīng)擴(kuò)展到了這個(gè)fixmap的fixaddress,很遺憾,成功了,然而它將stack vma     // 一刀切成了兩段。不管怎樣,訪問還是可以進(jìn)行的。     p_map = (char *)mmap((void*)p_base2, PAGESIZE*3, PROT_READ | PROT_WRITE,                         MAP_FIXED |MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);     if (p_map == MAP_FAILED) {         printf("failed 2\n");     }     printf("after second fixmap around stack at the same address\n");     getchar();     // 這里更狠!部分unmap了上面那個(gè)fixmap vma,留下一個(gè)空洞。     munmap(p_map, PAGESIZE);     printf("after unmap fixmap around stack incompletely\n");     getchar();     // 當(dāng)空洞被touch的時(shí)候,不會(huì)引發(fā)stack extend!而是直接segfault!爆炸!     call();     // 永遠(yuǎn)不會(huì)到達(dá)這里!     printf("after extend stack[second]\n");     getchar();     return 0; }

針對(duì)上述代碼的圖解

下面一幅圖展示一直到出事之前,該進(jìn)程的stack附近的地址空間映射區(qū)域是怎么演化的:

請(qǐng)使勁回答一個(gè)關(guān)于UNIX/Linux自動(dòng)擴(kuò)展stack的問

下面一幅圖展示出事的過程以及這個(gè)事故的原因:

請(qǐng)使勁回答一個(gè)關(guān)于UNIX/Linux自動(dòng)擴(kuò)展stack的問

測(cè)試方式

如 果你覺得圖是我自己畫出來的,那么肯定有一個(gè)疑問,我是基于什么畫出來的,事實(shí)上,我并不是通過看代碼畫出來的,我是通過不斷查看procfs的maps 文件實(shí)時(shí)了解該進(jìn)程地址空間的細(xì)節(jié),將其轉(zhuǎn)換成了上面的圖示,為了讓我有機(jī)會(huì)到另一個(gè)終端去查maps文件,我在代碼中增加了getchar調(diào)用,每次查 看完maps文件,我會(huì)拍一下鍵盤的回車鍵。我的測(cè)試如下:

代碼編譯后的進(jìn)程輸出

root@abcd:~# ./a.out
7846
init state

before unmap fixmap around stack

after unmap fixmap around stack

after extend stack[first]

after second fixmap around stack at the same address

after unmap fixmap around stack incompletely

段錯(cuò)誤 (core dumped)

以下是查看每一步進(jìn)程maps文件的輸出:

root@abcd:~# cat /proc/`ps -e|grep a.out|awk '{print $1}'`/maps |tail -n 6|head -n 4
2b2c01483000-2b2c01487000 r--p 00157000 fe:00 387296                    /lib/libc-2.11.2.so
2b2c01487000-2b2c01488000 rw-p 0015b000 fe:00 387296                    /lib/libc-2.11.2.so
2b2c01488000-2b2c0148f000 rw-p 00000000 00:00 0
7fff6236a000-7fff6237f000 rw-p 00000000 00:00 0                         [stack]
root@abcd:~# cat /proc/`ps -e|grep a.out|awk '{print $1}'`/maps |tail -n 6|head -n 4
2b2c01487000-2b2c01488000 rw-p 0015b000 fe:00 387296                    /lib/libc-2.11.2.so
2b2c01488000-2b2c0148f000 rw-p 00000000 00:00 0
7fff62359000-7fff6235c000 rw-p 00000000 00:00 0
7fff6236a000-7fff6237f000 rw-p 00000000 00:00 0                         [stack]
root@abcd:~# cat /proc/`ps -e|grep a.out|awk '{print $1}'`/maps |tail -n 6|head -n 4
2b2c01483000-2b2c01487000 r--p 00157000 fe:00 387296                    /lib/libc-2.11.2.so
2b2c01487000-2b2c01488000 rw-p 0015b000 fe:00 387296                    /lib/libc-2.11.2.so
2b2c01488000-2b2c0148f000 rw-p 00000000 00:00 0
7fff6236a000-7fff6237f000 rw-p 00000000 00:00 0                         [stack]
root@abcd:~# cat /proc/`ps -e|grep a.out|awk '{print $1}'`/maps |tail -n 6|head -n 4
2b2c01483000-2b2c01487000 r--p 00157000 fe:00 387296                    /lib/libc-2.11.2.so
2b2c01487000-2b2c01488000 rw-p 0015b000 fe:00 387296                    /lib/libc-2.11.2.so
2b2c01488000-2b2c0148f000 rw-p 00000000 00:00 0
7fff5e0bb000-7fff6237f000 rw-p 00000000 00:00 0                         [stack]
root@abcd:~# cat /proc/`ps -e|grep a.out|awk '{print $1}'`/maps |tail -n 6|head -n 4
2b2c01488000-2b2c0148f000 rw-p 00000000 00:00 0
7fff5e0bb000-7fff62359000 rw-p 00000000 00:00 0
7fff62359000-7fff6235c000 rw-p 00000000 00:00 0
7fff6235d000-7fff6237f000 rw-p 00000000 00:00 0                         [stack]
root@abcd:~# cat /proc/`ps -e|grep a.out|awk '{print $1}'`/maps |tail -n 6|head -n 4
2b2c01488000-2b2c0148f000 rw-p 00000000 00:00 0
7fff5e0bb000-7fff62359000 rw-p 00000000 00:00 0
7fff6235a000-7fff6235c000 rw-p 00000000 00:00 0
7fff6235d000-7fff6237f000 rw-p 00000000 00:00 0                         [stack]

我怕上面的文字信息太亂,格式在不同瀏覽器會(huì)有問題,我還特意截了一張圖:

請(qǐng)使勁回答一個(gè)關(guān)于UNIX/Linux自動(dòng)擴(kuò)展stack的問

有什么用

你 可以用這種方式徹底限制一個(gè)進(jìn)程的stack的大小,越界了不是報(bào)錯(cuò),而是segfault。然后你可以signal捕獲這個(gè)segfault,在里面把 那個(gè)未完全unmap的fixmap vma以及那個(gè)可憐且孤獨(dú)的殘缺的stack vma給徹底u(yù)nmap掉。不過這確實(shí)沒什么好玩的。有什么用呢?它的作用就是讓你更加深入理解Linux對(duì)虛擬地址空間的管理方式。

小Tips

本文不涉及線程棧,但是倒也不難,線程棧一般在heap區(qū)或者中間的大塊mmap區(qū)動(dòng)態(tài)分配,mmap的時(shí)候給它一個(gè)MAP_GROWSDOWN標(biāo)志就可以了。關(guān)于它的管理方式,沒啥差別。核心問題在于,缺頁(yè)異常處理程序是怎么識(shí)別到一個(gè)缺頁(yè)是一個(gè)vma內(nèi)部的缺頁(yè)(結(jié)果就是調(diào)頁(yè)),還是vma外部的缺頁(yè)。在后一種情況下,缺頁(yè)處理邏輯還要進(jìn)一步識(shí)別是stack的缺頁(yè)(結(jié)果就是extend stack然后調(diào)頁(yè)),還是非stack缺頁(yè)(結(jié)果就是segfault...)。
      Linux的stack除非遇到本文所述的這種方式的擠兌收縮,它是永遠(yuǎn)擴(kuò)展的。如果你想閱讀Linux的內(nèi)核代碼,那么也需要理解下面的事實(shí):
1.find_vma函數(shù)能找到vma只有一個(gè)限制,即輸入地址只要小于查找vma的end即可,并非很多人想象的那樣輸入地址必須處在查找vma的start和end之間;
2.find_vma函數(shù)之所以實(shí)現(xiàn)得如此incompletely,是因?yàn)闉榱撕?jiǎn)化缺頁(yè)中斷的處理,同時(shí)也是為了提供一種更加統(tǒng)一的方式同時(shí)處理upgrows和downgrows的vma。

后話

雖 然這個(gè)問題問得有點(diǎn)亂,但是如果能找上述回答連續(xù)扯5分鐘的,應(yīng)該是真行!不過我不知道怎樣的語(yǔ)言表達(dá)能力可以不用圖解和代碼把上面的每一個(gè)細(xì)節(jié)說清 楚...總之,我覺得我的這個(gè)題目是一個(gè)好題目??梢越ㄗh給看到此文的人,把它做面試題吧。凡是發(fā)現(xiàn)不了題目問題的以及說不出所以然的,一律不要!這真是 一道好測(cè)試題啊,它是如此之好,以至于我還想再出幾道比它更好的。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn,海內(nèi)外云服務(wù)器15元起步,三天無理由+7*72小時(shí)售后在線,公司持有idc許可證,提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì),專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。


名稱欄目:請(qǐng)使勁回答一個(gè)關(guān)于UNIX/Linux自動(dòng)擴(kuò)展stack的問-創(chuàng)新互聯(lián)
網(wǎng)頁(yè)地址:http://weahome.cn/article/psesc.html

其他資訊

在線咨詢

微信咨詢

電話咨詢

028-86922220(工作日)

18980820575(7×24)

提交需求

返回頂部