linux棧堆
Ⅰ linux下main函數的參數是在棧里還是在堆里
不是的. 每一個函數就是一個堆棧. 每調用一次, 都會有指針指向它. 而變數是加在這些堆棧中的(C語言一般是在堆棧的棧頂, C++都是哪用到在哪)
學高級語言的這些一般是不用在意的, 只有學匯編才用管它.
Ⅱ linux 設置堆棧大小 為無限制
你好。
執行命令ulimit -a，查看棧大小的限制。
通過使用 ulimit -s 數字 進行設置。
Ⅲ 怎麼解決 LINUX 堆棧溢出內存的問題
【緩沖區溢出的處理】
你屋子裡的門和窗戶越少，入侵者進入的方式就越少……
由於緩沖區溢出是一個編程問題，所以只能通過修復被破壞的程序的代碼而解決問題。如果你沒有源代碼，從上面「堆棧溢出攻擊」的原理可以看出，要防止此類攻擊，我們可以：
① 開放程序時仔細檢查溢出情況，不允許數據溢出緩沖區。由於編程和編程語言的原因，這非常困難，而且不適合大量已經在使用的程序；
② 使用檢查堆棧溢出的編譯器或者在程序中加入某些記號，以便程序運行時確認禁止黑客有意造成的溢出。問題是無法針對已有程序，對新程序來講，需要修改編譯器；
③ 經常檢查你的操作系統和應用程序提供商的站點，一旦發現他們提供的補丁程序，就馬上下載並且應用在系統上，這是最好的方法。但是系統管理員總要比攻擊者慢 一步，如果這個有問題的軟體是可選的，甚至是臨時的，把它從你的系統中刪除。舉另外一個例 子，你屋子裡的門和窗戶越少，入侵者進入的方式就越少。
----------------------------------------------------------------------------------------------------------------------------------------
char buf[3];
memset(buf,0x55,10);
這個程序就存在溢出
對數據塊的訪問超出該數據塊的地址范圍
===================================================================================
【一個檢測工具】
Valgrind 是一款 Linux下（支持 x86、x86_64和ppc32）程序的內存調試工具，它可以對編譯後的二進製程序進行內存使用監測（C語言中的 malloc 和 free，以及 C++ 中的 new 和 delete），找出內存泄漏問題。
Valgrind 中包含的 Memcheck 工具可以檢查以下的程序錯誤：
使用未初始化的內存 (Use of uninitialised memory)
使用已經釋放了的內存 （Reading/writing memory after it has been free』d）
使用超過 malloc 分配的內存空間（Reading/writing off the end of malloc』d blocks）
對堆棧的非法訪問（Reading/writing inappropriate areas on the stack）
申請的空間是否有釋放（Memory leaks – where pointers to malloc』d blocks are lost forever）
malloc/free/new/delete 申請和釋放內存的匹配（Mismatched use of malloc/new/new [] vs free/delete/delete []）
src 和 dst 的重疊（Overlapping src and dst pointers in memcpy() and related functions）
重復 free
① 編譯安裝 Valgrind：
# wget http://valgrind.org/downloads/valgrind-3.4.1.tar.bz2
# tar xvf valgrind-3.4.1.tar.bz2
# cd valgrind-3.4.1/
# ./configure
…………
Primary build target: X86_LINUX
Secondary build target:
Default supp files: exp-ptrcheck.supp xfree-3.supp xfree-4.supp glibc-2.X-drd.supp glibc-2.34567-NPTL-helgrind.supp glibc-2.5.supp
# make
# make install
# whereis valgrind
valgrind:
/usr/bin/valgrind
/usr/lib/valgrind
/usr/local/bin/valgrind
/usr/local/lib/valgrind
/usr/include/valgrind
/usr/share/man/man1/valgrind.1.gz
運行程序
使用示例：對「ls」程序進程檢查，返回結果中的「definitely lost: 0 bytes in 0 blocks.」表示沒有內存泄漏。
# /usr/local/bin/valgrind --tool=memcheck --leak-check=full ls /
==29801== Memcheck, a memory error detector.
==29801== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==29801== Using LibVEX rev 1884, a library for dynamic binary translation.
==29801== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==29801== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==29801== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==29801== For more details, rerun with: -v
==29801==
bin etc lost+found mnt proc selinux sys usr
boot home media net root smokeping tftpboot var
dev lib misc opt sbin srv tmp
==29801==
==29801== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 21 from 1)
==29801== malloc/free: in use at exit: 14,744 bytes in 32 blocks.
==29801== malloc/free: 162 allocs, 130 frees, 33,758 bytes allocated.
==29801== For counts of detected errors, rerun with: -v
==29801== searching for pointers to 32 not-freed blocks.
==29801== checked 139,012 bytes.
==29801==
==29801== LEAK SUMMARY:
==29801== definitely lost: 0 bytes in 0 blocks.
==29801== possibly lost: 0 bytes in 0 blocks.
==29801== still reachable: 14,744 bytes in 32 blocks.
==29801== suppressed: 0 bytes in 0 blocks.
==29801== Reachable blocks (those to which a pointer was found) are not shown.
==29801== To see them, rerun with: --leak-check=full --show-reachable=yes
----------------------------------------------------------------------------------------------------------------------------------------
# /usr/local/bin/valgrind --tool=memcheck --leak-check=full ps /
==29898== Memcheck, a memory error detector.
==29898== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==29898== Using LibVEX rev 1884, a library for dynamic binary translation.
==29898== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==29898== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==29898== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==29898== For more details, rerun with: -v
==29898==
ERROR: Garbage option.
********* simple selection ********* ********* selection by list *********
-A all processes -C by command name
-N negate selection -G by real group ID (supports names)
-a all w/ tty except session leaders -U by real user ID (supports names)
-d all except session leaders -g by session OR by effective group name
-e all processes -p by process ID
T all processes on this terminal -s processes in the sessions given
a all w/ tty, including other users -t by tty
g OBSOLETE -- DO NOT USE -u by effective user ID (supports names)
r only running processes U processes for specified users
x processes w/o controlling ttys t by tty
*********** output format ********** *********** long options ***********
-o,o user-defined -f full --Group --User --pid --cols --ppid
-j,j job control s signal --group --user --sid --rows --info
-O,O preloaded -o v virtual memory --cumulative --format --deselect
-l,l long u user-oriented --sort --tty --forest --version
-F extra full X registers --heading --no-heading --context
********* misc options *********
-V,V show version L list format codes f ASCII art forest
-m,m,-L,-T,H threads S children in sum -y change -l format
-M,Z security data c true command name -c scheling class
-w,w wide output n numeric WCHAN,UID -H process hierarchy
==29898==
==29898== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 14 from 1)
==29898== malloc/free: in use at exit: 16 bytes in 2 blocks.
==29898== malloc/free: 20 allocs, 18 frees, 2,344 bytes allocated.
==29898== For counts of detected errors, rerun with: -v
==29898== searching for pointers to 2 not-freed blocks.
==29898== checked 263,972 bytes.
==29898==
==29898== 8 bytes in 1 blocks are definitely lost in loss record 2 of 2
==29898== at 0x4005A88: malloc (vg_replace_malloc.c:207)
==29898== by 0xBFF6DF: strp (in /lib/libc-2.5.so)
==29898== by 0x804A464: (within /bin/ps)
==29898== by 0x804A802: (within /bin/ps)
==29898== by 0x804964D: (within /bin/ps)
==29898== by 0xBA5E8B: (below main) (in /lib/libc-2.5.so)
==29898==
==29898== LEAK SUMMARY:
==29898== definitely lost: 8 bytes in 1 blocks.
==29898== possibly lost: 0 bytes in 0 blocks.
==29898== still reachable: 8 bytes in 1 blocks.
==29898== suppressed: 0 bytes in 0 blocks.
==29898== Reachable blocks (those to which a pointer was found) are not shown.
==29898== To see them, rerun with: --leak-check=full --show-reachable=yes
Ⅳ 堆(heap)和棧(Stack)的區別是什麼為什麼平時都把堆棧放在一起講
將堆跟棧放在一起將是因為兩者都是存儲數據的方式。區別如下：
一、主體不同
1、堆：是計算機科學中一類特殊的數據結構的統稱。堆通常是一個可以被看做一棵完全二叉樹的數組對象。
2、棧：又名堆棧，它是一種運算受限的線性表。限定僅在表尾進行插入和刪除操作的線性表。
二、特點不同
1、堆：堆中某個節點的值總是不大於或不小於其父節點的值；堆總是一棵完全二叉樹。
2、棧：是一種只能在一端進行插入和刪除操作的特殊線性表。它按照先進後出的原則存儲數據，先進入的數據被壓入棧底，最後的數據在棧頂。
三、作用不同
1、堆：堆是非線性數據結構，相當於一維數組，有兩個直接後繼。
2、棧：可以用來在函數調用的時候存儲斷點，做遞歸時要用到棧。
Ⅳ linux系統最大堆棧內存
linux系統最大堆棧內存是-Xmx512m。根據查找相關公開資料顯示，linux系統堆棧大小的配置啟動參數，初始堆大小-Xms32m最大堆大小-Xmx512m。
Ⅵ 有沒有人知道，windows和linux下的棧和堆的地址范圍分別是多少
這句話的意思是棧頂的地址和棧的最大容量是系統預先規定好的，在WINDOWS下，棧的大小是2M（也有的說是1M，總之是一個編譯時就確定的常數），如果申請的空間超過棧的剩餘空間時，將提示overflow。因此，能從棧獲得的空間較小。 堆：堆是向高地址擴展的數據結構，是不連續的內存區域。這是由於系統是用鏈表來存儲的空閑內存地址的，自然是不連續的，而鏈表的遍歷方向是由低地址向高地址。堆的大小受限於計算機系統中有效的虛擬內存。
Ⅶ 求教關於linux的堆棧設置
在/etc/profile 的最後面添加ulimit -s unlimited 保存，source /etc/profile使修改文件生效
linux查看修改線程默認棧空間大小 ：ulimit -s
1、通過命令 ulimit -s 查看linux的默認棧空間大小，默認情況下 為10240 即10M
2、通過命令 ulimit -s 設置大小值 臨時改變棧空間大小：ulimit -s 102400， 即修改為100M
3、可以在/etc/rc.local 內 加入 ulimit -s 102400 則可以開機就設置棧空間大小
4、在/etc/security/limits.conf 中也可以改變棧空間大小：
#<domain> <type> <item> <value>
* soft stack 102400
重新登錄，執行ulimit -s 即可看到改為102400 即100M
Ⅷ Linux內核中用戶空間棧和內核棧的區別
您好，很高興為您解答。
1.進程的堆棧
內核在創建進程的時候，在創建task_struct的同事，會為進程創建相應的堆棧。每個進程會有兩個棧，一個用戶棧，存在於用戶空間，一個內核棧，存在於內核空間。當進程在用戶空間運行時，cpu堆棧指針寄存器裡面的內容是用戶堆棧地址，使用用戶棧；當進程在內核空間時，cpu堆棧指針寄存器裡面的內容是內核棧空間地址，使用內核棧。
2.進程用戶棧和內核棧的切換
當進程因為中斷或者系統調用而陷入內核態之行時，進程所使用的堆棧也要從用戶棧轉到內核棧。
進程陷入內核態後，先把用戶態堆棧的地址保存在內核棧之中，然後設置堆棧指針寄存器的內容為內核棧的地址，這樣就完成了用戶棧向內核棧的轉換；當進程從內核態恢復到用戶態之行時，在內核態之行的最後將保存在內核棧裡面的用戶棧的地址恢復到堆棧指針寄存器即可。這樣就實現了內核棧和用戶棧的互轉。
那麼，我們知道從內核轉到用戶態時用戶棧的地址是在陷入內核的時候保存在內核棧裡面的，但是在陷入內核的時候，我們是如何知道內核棧的地址的呢？
關鍵在進程從用戶態轉到內核態的時候，進程的內核棧總是空的。這是因為，當進程在用戶態運行時，使用的是用戶棧，當進程陷入到內核態時，內核棧保存進程在內核態運行的相關信心，但是一旦進程返回到用戶態後，內核棧中保存的信息無效，會全部恢復，因此每次進程從用戶態陷入內核的時候得到的內核棧都是空的。所以在進程陷入內核的時候，直接把內核棧的棧頂地址給堆棧指針寄存器就可以了。
3.內核棧的實現
內核棧在kernel-2.4和kernel-2.6裡面的實現方式是不一樣的。
在kernel-2.4內核裡面，內核棧的實現是：
Uniontask_union{
Structtask_structtask;
Unsignedlongstack[INIT_STACK_SIZE/sizeof(long)];
};其中，INIT_STACK_SIZE的大小隻能是8K。
內核為每個進程分配task_struct結構體的時候，實際上分配兩個連續的物理頁面，底部用作task_struct結構體，結構上面的用作堆棧。使用current()宏能夠訪問當前正在運行的進程描述符。
注意：這個時候task_struct結構是在內核棧裡面的，內核棧的實際能用大小大概有7K。
內核棧在kernel-2.6裡面的實現是（kernel-2.6.32）：
Unionthread_union{
Structthread_infothread_info；
Unsignedlongstack[THREAD_SIZE/sizeof(long)];
};其中THREAD_SIZE的大小可以是4K，也可以是8K，thread_info佔52bytes。
當內核棧為8K時，Thread_info在這塊內存的起始地址，內核棧從堆棧末端向下增長。所以此時，kernel-2.6中的current宏是需要更改的。要通過thread_info結構體中的task_struct域來獲得於thread_info相關聯的task。更詳細的參考相應的current宏的實現。
structthread_info{
structtask_struct*task；
structexec_domain*exec_domain；
__u32flags；
__u32status;
__u32cpu;
…..
};注意：此時的task_struct結構體已經不在內核棧空間裡面了。
如若滿意，請點擊右側【採納答案】，如若還有問題，請點擊【追問】
希望我的回答對您有所幫助，望採納！
~ O(∩_∩)O~
Ⅸ linux程序設計：堆和棧的區別
一、預備知識—程序的內存分配
一個由C/C++編譯的程序佔用的內存分為以下幾個部分
1、棧區（stack）— 由編譯器自動分配釋放 ，存放函數的參數值，局部變數的值等。其
操作方式類似於數據結構中的棧。
2、堆區（heap） — 一般由程序員分配釋放， 若程序員不釋放，程序結束時可能由OS回
收 。注意它與數據結構中的堆是兩回事，分配方式倒是類似於鏈表，呵呵。
3、全局區（靜態區）（static）—，全局變數和靜態變數的存儲是放在一塊的，初始化的
全局變數和靜態變數在一塊區域， 未初始化的全局變數和未初始化的靜態變數在相鄰的另
一塊區域。 - 程序結束後由系統釋放。
4、文字常量區 —常量字元串就是放在這里的。 程序結束後由系統釋放
5、程序代碼區—存放函數體的二進制代碼。
二、例子程序
這是一個前輩寫的，非常詳細
//main.cpp
int a = 0; 全局初始化區
char *p1; 全局未初始化區
main()
{
int b; 棧
char s[] = "abc"; 棧
char *p2; 棧
char *p3 = "123456"; 123456/0在常量區，p3在棧上。
static int c =0； 全局（靜態）初始化區
p1 = (char *)malloc(10);
p2 = (char *)malloc(20);
分配得來得10和20位元組的區域就在堆區。
strcpy(p1, "123456"); 123456/0放在常量區，編譯器可能會將它與p3所指向的"123456"
優化成一個地方。
}
二、堆和棧的理論知識
2.1申請方式
stack:
由系統自動分配。 例如，聲明在函數中一個局部變數 int b; 系統自動在棧中為b開辟空
間
heap:
需要程序員自己申請，並指明大小，在c中malloc函數
如p1 = (char *)malloc(10);
在C++中用new運算符
如p2 = new char[10];
但是注意p1、p2本身是在棧中的。
2.2
申請後系統的響應
棧：只要棧的剩餘空間大於所申請空間，系統將為程序提供內存，否則將報異常提示棧溢
出。
堆：首先應該知道操作系統有一個記錄空閑內存地址的鏈表，當系統收到程序的申請時，
會遍歷該鏈表，尋找第一個空間大於所申請空間的堆結點，然後將該結點從空閑結點鏈表
中刪除，並將該結點的空間分配給程序，另外，對於大多數系統，會在這塊內存空間中的
首地址處記錄本次分配的大小，這樣，代碼中的delete語句才能正確的釋放本內存空間。
另外，由於找到的堆結點的大小不一定正好等於申請的大小，系統會自動的將多餘的那部
分重新放入空閑鏈表中。
2.3申請大小的限制
棧：在Windows下,棧是向低地址擴展的數據結構，是一塊連續的內存的區域。這句話的意
思是棧頂的地址和棧的最大容量是系統預先規定好的，在WINDOWS下，棧的大小是2M（也有
的說是1M，總之是一個編譯時就確定的常數），如果申請的空間超過棧的剩餘空間時，將
提示overflow。因此，能從棧獲得的空間較小。
堆：堆是向高地址擴展的數據結構，是不連續的內存區域。這是由於系統是用鏈表來存儲
的空閑內存地址的，自然是不連續的，而鏈表的遍歷方向是由低地址向高地址。堆的大小
受限於計算機系統中有效的虛擬內存。由此可見，堆獲得的空間比較靈活，也比較大。
2.4申請效率的比較：
棧由系統自動分配，速度較快。但程序員是無法控制的。
堆是由new分配的內存，一般速度比較慢，而且容易產生內存碎片,不過用起來最方便.
另外，在WINDOWS下，最好的方式是用VirtualAlloc分配內存，他不是在堆，也不是在棧是
直接在進程的地址空間中保留一塊內存，雖然用起來最不方便。但是速度快，也最靈活。
2.5堆和棧中的存儲內容
棧： 在函數調用時，第一個進棧的是主函數中後的下一條指令（函數調用語句的下一條可
執行語句）的地址，然後是函數的各個參數，在大多數的C編譯器中，參數是由右往左入棧
的，然後是函數中的局部變數。注意靜態變數是不入棧的。
當本次函數調用結束後，局部變數先出棧，然後是參數，最後棧頂指針指向最開始存的地
址，也就是主函數中的下一條指令，程序由該點繼續運行。
堆：一般是在堆的頭部用一個位元組存放堆的大小。堆中的具體內容由程序員安排。
2.6存取效率的比較
char s1[] = "aaaaaaaaaaaaaaa";
char *s2 = "bbbbbbbbbbbbbbbbb";
aaaaaaaaaaa是在運行時刻賦值的；
而bbbbbbbbbbb是在編譯時就確定的；
但是，在以後的存取中，在棧上的數組比指針所指向的字元串(例如堆)快。
比如：
#include
void main()
{
char a = 1;
char c[] = "1234567890";
char *p ="1234567890";
a = c[1];
a = p[1];
return;
}
對應的匯編代碼
10: a = c[1];
00401067 8A 4D F1 mov cl,byte ptr [ebp-0Fh]
0040106A 88 4D FC mov byte ptr [ebp-4],cl
11: a = p[1];
0040106D 8B 55 EC mov edx,dword ptr [ebp-14h]
00401070 8A 42 01 mov al,byte ptr [edx+1]
00401073 88 45 FC mov byte ptr [ebp-4],al
第一種在讀取時直接就把字元串中的元素讀到寄存器cl中，而第二種則要先把指針值讀到
edx中，再根據edx讀取字元，顯然慢了。
2.7小結：
堆和棧的區別可以用如下的比喻來看出：
使用棧就象我們去飯館里吃飯，只管點菜（發出申請）、付錢、和吃（使用），吃飽了就 走，不必理會切菜、洗菜等准備工作和洗碗、刷鍋等掃尾工作，他的好處是快捷，但是自 由度小。
使用堆就象是自己動手做喜歡吃的菜餚，比較麻煩，但是比較符合自己的口味，而且自由
Ⅹ 進程內核棧，用戶棧及 Linux 進程棧和線程棧的區別
內核棧、用戶棧
32位Linux系統上，進程的地址空間為4G，包括1G的內核地址空間-----內核棧，和3G的用戶地址空間-----用戶棧。
內核棧，是各個進程在剛開始建立的時候通過內存映射共享的，但是每個進程擁有獨立的4G的虛擬內存空間從這一點看又是獨立的，互不幹擾的（只是剛開始大家都是映射的同一份內存拷貝）
用戶棧就是大家所熟悉的內存四區，包括：代碼區、全局數據區、堆區、棧區
用戶棧中的堆區、棧區即為進程堆、進程棧
進程堆、進程棧與線程棧
1.線程棧的空間開辟在所屬進程的堆區與共享內存區之間，線程與其所屬的進程共享進程的用戶空間，所以線程棧之間可以互訪。線程棧的起始地址和大小存放在pthread_attr_t 中，棧的大小並不是用來判斷棧是否越界，而是用來初始化避免棧溢出的緩沖區的大小（或者說安全間隙的大小）
2.進程初始化的時候，系統會在進程的地址空間中創建一個堆，叫進程默認堆。進程中所有的線程共用這一個堆。當然，可以增加1個或幾個堆，給不同的線程共同使用或單獨使用。----一個進程可以多個堆
3、創建線程的時候，系統會在進程的地址空間中分配1塊內存給線程棧，通常是1MB或4MB或8MB。線程棧是獨立的，但是還是可以互訪，因為線程共享內存空間
4.堆的分配：從操作系統角度來看，進程分配內存有兩種方式，分別由兩個系統調用完成：brk（）和mmap（），glibc中malloc封裝了
5.線程棧位置-內存分布測試代碼
[cpp] view plain
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <malloc.h>
#include <sys/syscall.h>
void* func(void* arg)
{
long int tid = (long int)syscall(SYS_gettid);
printf("The ID of this thread is: %ld\n", tid );
static int a=10;
int b=11;
int* c=(int *)malloc(sizeof(int));
printf("in thread id:%u a:%p b:%p c:%p\n",tid,&a,&b,c);
printf("leave thread id:%ld\n",tid);
sleep(20);
free((void *)c);
}
void main()
{
pthread_t th1,th2;
printf("pid=%u\n",(int)getpid());
func(NULL);
int ret=pthread_create(&th1,NULL,func,NULL);
if(ret!=0)
{
printf("thread1[%d]:%s\n",th1,strerror(errno));
}
ret=pthread_create(&th2,NULL,func,NULL);
if(ret!=0)
{
printf("thread2[%d]:%s\n",th2,strerror(errno));
}
pthread_join(th1,NULL);
pthread_join(th2,NULL);
}
輸出：
[le@localhost threadStack]$ ./threadStack_main pid=16433
The ID of this thread is: 16433
in thread id:16433 a:0x60107c b:0x7fffc89ce7ac c:0x1b54010
leave thread id:16433
The ID of this thread is: 16461
The ID of this thread is: 16460
in thread id:16461 a:0x60107c b:0x7f6abb096efc c:0x7f6ab40008c0
leave thread id:16461
in thread id:16460 a:0x60107c b:0x7f6abb897efc c:0x7f6aac0008c0
leave thread id:16460
主線程調用func後
[le@localhost threadStack]$ sudo cat /proc/16433/maps
00400000-00401000 r-xp 00000000 fd:02 11666 /home/le/code/threadStack/threadStack_main
00600000-00601000 r--p 00000000 fd:02 11666 /home/le/code/threadStack/threadStack_main
00601000-00602000 rw-p 00001000 fd:02 11666 /home/le/code/threadStack/threadStack_main
01b54000-01b75000 rw-p 00000000 00:00 0 [heap]
7f6abb899000-7f6abba4f000 r-xp 00000000 fd:00 100678959 /usr/lib64/libc-2.17.so
7f6abba4f000-7f6abbc4f000 ---p 001b6000 fd:00 100678959 /usr/lib64/libc-2.17.so
7f6abbc4f000-7f6abbc53000 r--p 001b6000 fd:00 100678959 /usr/lib64/libc-2.17.so
7f6abbc53000-7f6abbc55000 rw-p 001ba000 fd:00 100678959 /usr/lib64/libc-2.17.so
7f6abbc55000-7f6abbc5a000 rw-p 00000000 00:00 0
7f6abbc5a000-7f6abbc70000 r-xp 00000000 fd:00 105796566 /usr/lib64/libpthread-2.17.so
7f6abbc70000-7f6abbe70000 ---p 00016000 fd:00 105796566 /usr/lib64/libpthread-2.17.so
7f6abbe70000-7f6abbe71000 r--p 00016000 fd:00 105796566 /usr/lib64/libpthread-2.17.so
7f6abbe71000-7f6abbe72000 rw-p 00017000 fd:00 105796566 /usr/lib64/libpthread-2.17.so
7f6abbe72000-7f6abbe76000 rw-p 00000000 00:00 0
7f6abbe76000-7f6abbe97000 r-xp 00000000 fd:00 105796545 /usr/lib64/ld-2.17.so
7f6abc073000-7f6abc076000 rw-p 00000000 00:00 0
7f6abc095000-7f6abc097000 rw-p 00000000 00:00 0
7f6abc097000-7f6abc098000 r--p 00021000 fd:00 105796545 /usr/lib64/ld-2.17.so
7f6abc098000-7f6abc099000 rw-p 00022000 fd:00 105796545 /usr/lib64/ld-2.17.so
7f6abc099000-7f6abc09a000 rw-p 00000000 00:00 0
7fffc89b0000-7fffc89d1000 rw-p 00000000 00:00 0 [stack]
7fffc89fe000-7fffc8a00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
兩個子線程啟動後
[le@localhost threadStack]$ sudo cat /proc/16433/maps
00400000-00401000 r-xp 00000000 fd:02 11666 /home/le/code/threadStack/threadStack_main
00600000-00601000 r--p 00000000 fd:02 11666 /home/le/code/threadStack/threadStack_main
00601000-00602000 rw-p 00001000 fd:02 11666 /home/le/code/threadStack/threadStack_main
01b54000-01b75000 rw-p 00000000 00:00 0 [heap]
7f6aac000000-7f6aac021000 rw-p 00000000 00:00 0
7f6aac021000-7f6ab0000000 ---p 00000000 00:00 0
7f6ab4000000-7f6ab4021000 rw-p 00000000 00:00 0
7f6ab4021000-7f6ab8000000 ---p 00000000 00:00 0
7f6aba897000-7f6aba898000 ---p 00000000 00:00 0
7f6aba898000-7f6abb098000 rw-p 00000000 00:00 0 [stack:16461]
7f6abb098000-7f6abb099000 ---p 00000000 00:00 0
7f6abb099000-7f6abb899000 rw-p 00000000 00:00 0 [stack:16460]
7f6abb899000-7f6abba4f000 r-xp 00000000 fd:00 100678959 /usr/lib64/libc-2.17.so
7f6abba4f000-7f6abbc4f000 ---p 001b6000 fd:00 100678959 /usr/lib64/libc-2.17.so
7f6abbc4f000-7f6abbc53000 r--p 001b6000 fd:00 100678959 /usr/lib64/libc-2.17.so
7f6abbc53000-7f6abbc55000 rw-p 001ba000 fd:00 100678959 /usr/lib64/libc-2.17.so
7f6abbc55000-7f6abbc5a000 rw-p 00000000 00:00 0
7f6abbc5a000-7f6abbc70000 r-xp 00000000 fd:00 105796566 /usr/lib64/libpthread-2.17.so
7f6abbc70000-7f6abbe70000 ---p 00016000 fd:00 105796566 /usr/lib64/libpthread-2.17.so
7f6abbe70000-7f6abbe71000 r--p 00016000 fd:00 105796566 /usr/lib64/libpthread-2.17.so
7f6abbe71000-7f6abbe72000 rw-p 00017000 fd:00 105796566 /usr/lib64/libpthread-2.17.so
7f6abbe72000-7f6abbe76000 rw-p 00000000 00:00 0
7f6abbe76000-7f6abbe97000 r-xp 00000000 fd:00 105796545 /usr/lib64/ld-2.17.so
7f6abc073000-7f6abc076000 rw-p 00000000 00:00 0
7f6abc095000-7f6abc097000 rw-p 00000000 00:00 0
7f6abc097000-7f6abc098000 r--p 00021000 fd:00 105796545 /usr/lib64/ld-2.17.so
7f6abc098000-7f6abc099000 rw-p 00022000 fd:00 105796545 /usr/lib64/ld-2.17.so
7f6abc099000-7f6abc09a000 rw-p 00000000 00:00 0
7fffc89b0000-7fffc89d1000 rw-p 00000000 00:00 0 [stack]
7fffc89fe000-7fffc8a00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]