1 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
Gustavo Duarte
Software, computers, and business.
Home
About
Articles
Subscribe
This does not mean the kernel uses that much physical memory, only that it has that portion of address space
available to map whatever physical memory it wishes. Kernel space is flagged in the page tables as exclusive
to privileged code (ring 2 or lower), hence a page fault is triggered if user-mode programs try to touch it. In
Linux, kernel space is constantly present and maps the same physical memory in all processes. Kernel code
and data are always addressable, ready to handle interrupts or system calls at any time. By contrast, the
mapping for the user-mode portion of the address space changes whenever a process switch happens:
2 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
Blue regions represent virtual addresses that are mapped to physical memory, whereas white regions are
unmapped. In the example above, Firefox has used far more of its virtual address space due to its legendary
memory hunger. The distinct bands in the address space correspond to memory segments like the heap,
stack, and so on. Keep in mind these segments are simply a range of memory addresses and have nothing to
do with Intel-style segments. Anyway, here is the standard segment layout in a Linux process:
When computing was happy and safe and cuddly, the starting virtual addresses for the segments shown above
were exactly the same for nearly every process in a machine. This made it easy to exploit security
vulnerabilities remotely. An exploit often needs to reference absolute memory locations: an address on the
stack, the address for a library function, etc. Remote attackers must choose this location blindly, counting on
the fact that address spaces are all the same. When they are, people get pwned. Thus address space
randomization has become popular. Linux randomizes the stack, memory mapping segment, and heap by
adding offsets to their starting addresses. Unfortunately the 32-bit address space is pretty tight, leaving little
room for randomization and hampering its effectiveness.
The topmost segment in the process address space is the stack, which stores local variables and function
parameters in most programming languages. Calling a method or function pushes a new stack frame onto the
stack. The stack frame is destroyed when the function returns. This simple design, possible because the data
obeys strict LIFO order, means that no complex data structure is needed to track stack contents a simple
13/01/2014 04:16 p.m.
3 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
pointer to the top of the stack will do. Pushing and popping are thus very fast and deterministic. Also, the
constant reuse of stack regions tends to keep active stack memory in the cpu caches, speeding up access.
Each thread in a process gets its own stack.
It is possible to exhaust the area mapping the stack by pushing more data than it can fit. This triggers a page
fault that is handled in Linux by expand_stack(), which in turn calls acct_stack_growth() to check whether
its appropriate to grow the stack. If the stack size is below RLIMIT_STACK (usually 8MB), then normally the
stack grows and the program continues merrily, unaware of what just happened. This is the normal
mechanism whereby stack size adjusts to demand. However, if the maximum stack size has been reached, we
have a stack overflow and the program receives a Segmentation Fault. While the mapped stack area expands
to meet demand, it does not shrink back when the stack gets smaller. Like the federal budget, it only expands.
Dynamic stack growth is the only situation in which access to an unmapped memory region, shown in white
above, might be valid. Any other access to unmapped memory triggers a page fault that results in a
Segmentation Fault. Some mapped areas are read-only, hence write attempts to these areas also lead to
segfaults.
Below the stack, we have the memory mapping segment. Here the kernel maps contents of files directly to
memory. Any application can ask for such a mapping via the Linux mmap() system call (implementation) or
CreateFileMapping() / MapViewOfFile() in Windows. Memory mapping is a convenient and
high-performance way to do file I/O, so it is used for loading dynamic libraries. It is also possible to create an
anonymous memory mapping that does not correspond to any files, being used instead for program data. In
Linux, if you request a large block of memory via malloc(), the C library will create such an anonymous
mapping instead of using heap memory. Large means larger than MMAP_THRESHOLD bytes, 128 kB by default
and adjustable via mallopt().
Speaking of the heap, it comes next in our plunge into address space. The heap provides runtime memory
allocation, like the stack, meant for data that must outlive the function doing the allocation, unlike the stack.
Most languages provide heap management to programs. Satisfying memory requests is thus a joint affair
between the language runtime and the kernel. In C, the interface to heap allocation is malloc() and friends,
whereas in a garbage-collected language like C# the interface is the new keyword.
If there is enough space in the heap to satisfy a memory request, it can be handled by the language runtime
without kernel involvement. Otherwise the heap is enlarged via the brk() system call (implementation) to
make room for the requested block. Heap management is complex, requiring sophisticated algorithms that
strive for speed and efficient memory usage in the face of our programs chaotic allocation patterns. The time
needed to service a heap request can vary substantially. Real-time systems have special-purpose allocators to
deal with this problem. Heaps also become fragmented, shown below:
Finally, we get to the lowest segments of memory: BSS, data, and program text. Both BSS and data store
contents for static (global) variables in C. The difference is that BSS stores the contents of uninitialized static
variables, whose values are not set by the programmer in source code. The BSS memory area is anonymous:
it does not map any file. If you say static int cntActiveUsers, the contents of cntActiveUsers live in
the BSS.
4 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
The data segment, on the other hand, holds the contents for static variables initialized in source code. This
memory area is not anonymous. It maps the part of the programs binary image that contains the initial static
values given in source code. So if you say static int cntWorkerBees = 10, the contents of cntWorkerBees
live in the data segment and start out as 10. Even though the data segment maps a file, it is a private memory
mapping, which means that updates to memory are not reflected in the underlying file. This must be the case,
otherwise assignments to global variables would change your on-disk binary image. Inconceivable!
The data example in the diagram is trickier because it uses a pointer. In that case, the contents of pointer
gonzo a 4-byte memory address live in the data segment. The actual string it points to does not, however.
The string lives in the text segment, which is read-only and stores all of your code in addition to tidbits like
string literals. The text segment also maps your binary file in memory, but writes to this area earn your
program a Segmentation Fault. This helps prevent pointer bugs, though not as effectively as avoiding C in the
first place. Heres a diagram showing these segments and our example variables:
You can examine the memory areas in a Linux process by reading the file /proc/pid_of_process/maps.
Keep in mind that a segment may contain many areas. For example, each memory mapped file normally has
its own area in the mmap segment, and dynamic libraries have extra areas similar to BSS and data. The next
post will clarify what area really means. Also, sometimes people say data segment meaning all of data +
bss + heap.
You can examine binary images using the nm and objdump commands to display symbols, their addresses,
segments, and so on. Finally, the virtual address layout described above is the flexible layout in Linux,
which has been the default for a few years. It assumes that we have a value for RLIMIT_STACK. When thats
not the case, Linux reverts back to the classic layout shown below:
5 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
Thats it for virtual address space layout. The next post discusses how the kernel keeps track of these memory
areas. Coming up well look at memory mapping, how file reading and writing ties into all this and what
memory usage figures mean.
January 27, 2009 at 12:34 am | Filed Under Internals, Linux, Software Illustrated
Subscribe to blog
184 Comments
Comments
184 Responses to Anatomy of a Program in Memory
1. JP on January 27th, 2009 12:53 am
Thank you!
Your posts are some of the most informative Ive ever found on the internet.
Im just researching this subject right now and your timing couldnt have been better!
Thanks!
2. Gustavo Duarte on January 27th, 2009 12:55 am
@JP: sweet, glad it came at a good time. Youre welcome!
3. michele alberti on January 27th, 2009 1:13 am
First of all: great job! Your written are very good!
I have a question. Im studying some code and I need documentation on Linux internals, specifically on
memory management about processes. Can you suggest me any books or other documentation?
6 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
Thanks!
4. Gustavo Duarte on January 27th, 2009 1:22 am
@michele: Take a look at the end of this post. It has a list of Linux kernel books.
My favorite book is still Understanding the Linux Kernel because it explains _everything_ in
painstaking detail. It is dry, but the authors put monumental effort into going through everything.
The Intel manuals are free and also excellent.
These books are the best resource I know of. I hope to write more material for this blog and eventually
maybe have a short Intro to the Linux Kernel document online. However this is subject to my work
schedule and so on.
5. michele alberti on January 27th, 2009 1:32 am
@Gustavo:
thanks very much.
The project Im studying needs to understand/manage memory stuff, like /proc//maps. Ill read the doc
you suggest me and keep reading your blog
thanks!
6. frgtn on January 27th, 2009 5:01 am
Thanks for a great post once again. Ive been reading your blog for a while now and found a lot of your
other posts really informative and easy to read. Big + goes for the diagrams, they help clarify on a lot
of points. Keep up the good work!
7. web development on January 27th, 2009 6:24 am
Great article!
Quite shocked to know that windows takes double the kernel memory compared to Linux.
8. numerodix on January 27th, 2009 6:39 am
Excellent writeup!
Im wondering, though, why does the kernel space consume 1gb? That seems like a lot..
And if you dont mind divulging a trade secret, what do you use to draw your diagrams?
9. Reader1 on January 27th, 2009 6:45 am
Great post. You left some stuff out though. In modern linux/windows OSs the heap base is also
randomized. And in Linux string literals such as char *blah = hello there; will be stored in an ELF
section called .rodata. Rarely is constant data such as strings held in .text, but it does happen. Good
post though, I like the graphics.
7 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
8 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
9 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
10 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
11 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
12 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
when loaded into memor and such nitty gritty details, it would be great!
49. Gustavo Duarte on February 2nd, 2009 8:40 am
Thank you all for the feedback.
@Prabhu: thats a great topic. Theres a good book about this called Linkers and Loaders. Its from
2000, not sure how much has changed since. Im going to add this to my write queue, though I have no
idea when the post would actually come out
50. bekars on February 3rd, 2009 12:29 am
Great works, Thank you
51. How The Kernel Manages Your Memory : Gustavo Duarte on February 3rd, 2009 11:36 pm
[...] examining the virtual address layout of a process, we turn to the kernel and its mechanisms for
managing user memory. Here is gonzo [...]
52. Asmita on February 4th, 2009 12:31 am
Its a great post Very helpfull. Im really waiting for the next one as Im not too clear for Heap
system. Keep writing. Thanks a lot for sharing these helpfull contents.
53. Software Quality Digest 2009-02-04 | No bug left behind on February 4th, 2009 12:49 pm
[...] Anatomy of a Program in Memory In-depth article by Gustavo Duarte about how a program is
represented in memory [...]
54. Nix on February 5th, 2009 7:01 am
Another excellent series on linkers is Ian Lance Taylors 20-article series starting near the bottom of
and proceeding onwards for several pages.
55. Nix on February 5th, 2009 7:01 am
Oh, curses. Fixed link to the linkers series start
56. Gustavo Duarte on February 5th, 2009 9:25 am
@Nix: great link, thanks!
57. How The Kernel Manages Your Memory | www.pwnage.ro on February 5th, 2009 12:46 pm
[...] Anatomy of a Program in Memory VN:F [1.0.9_379]please waitRating: 0.0/10 (0 votes cast) [...]
58. Raminder on February 7th, 2009 10:47 am
Hi Gustavo, thank you for all your excellent articles.
I have a question, two actually. As youve said each thread has its own stack area. How are these stack
areas located with respect to each other? e.g if there are two threads in a process T1 & T2 where would
their stacks start and end in the memory. The second question is similar. Does each thread has two
13 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
stacks one for user mode and one for kernel mode?
59. macosx on February 8th, 2009 10:34 pm
Great jobs.keep going on and publishing more articles
60. Gustavo Duarte on February 10th, 2009 12:54 am
@Raminder: youre welcome! Sorry for the delay in an answer here, but Ive been swamped with work
these past few days. Can you drop me an email so that I can let you know when Ive replied here?
61. Gustavo Duarte on February 13th, 2009 12:21 am
@Raminder: Sorry for the delay, Ive been working a bit lately. Per our email, Ill talk about Windows
only.
I dont know where in the virtual space the thread stacks go. I googled briefly but didnt see an answer,
so I think the easiest thing to do is to write a short test program to spawn a few threads calling a
function that prints the address of a local variable. If you do a loop of 10 or so the pattern should
become clear. I found two relevant posts;
http://blogs.msdn.com/oldnewthing/archive/2005/07/29/444912.aspx
http://software.intel.com/en-us/articles/adjusting-thread-stack-address-to-improve-performanceon-intel-xeonr-processors/
Regarding the second question, YES, threads have two stacks: a large one for user mode (1MB by
default it looks like) and a tiny one for kernel mode (just a few kilobytes, 12k for x86). The kernel
stack is kept in kernel-mode data structures and cant be touched from user mode.
Hope this helps.
62. Jakcy on February 17th, 2009 11:36 pm
I am from China. Although my English is not so good, but I like your articles. I am ready to reading all
your articles on your blog.
Greate Job And Execllent Articles~~~
63. Ya-tou & me Blog Archive How The Kernel Manages Your Memory on February 19th, 2009 1:43
am
[...] examining the virtual address layout of a process, we turn to the kernel and its mechanisms for
managing user memory. Here is gonzo [...]
64. La anatoma de un programa en memoria Mbpfernand0s Blog on February 26th, 2009 9:38 am
[...] todo caso, interesante documento en Anatomy of a Program in Memory que describe la gestin de
memoria alrededor de un [...]
65. Alex on March 8th, 2009 6:36 pm
Great post. Congratulations! Some questions, so what I understood is that a process can not use more
14 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
than 3gb in a default running linux system, since 1gb is reserved for the kernel, is this true or not? I
remember that Ive seen processes that are using more than 3gbm as far as top is concerned, but I could
be wrong (32bit system). Also for example, for top, why isnt the 1gb, reserved for the kernel, added in
the VIRT space?
66. Justin Blanton | Anatomy of a program in memory on March 12th, 2009 10:41 pm
[...] Anatomy of a program in memory. [...]
67. birumut on March 18th, 2009 11:13 am
thank you very much, in fact it is very useful for me
68. Nagareddy on March 20th, 2009 12:59 pm
Very useful and comprehensiv , to point..
How do you know windows size limits?
69. Gustavo Duarte on March 23rd, 2009 6:40 pm
@Nagareddy: which size limits? But regardless of which limits, they probably are either from the
Windows Internals book, Windows header files, or Intel literature
70. Gustavo Duarte on March 23rd, 2009 6:53 pm
@Alex,
Thanks! Thats right, a process cant use more than 3GB of RAM. Thats why for example the
memcached folks tell you to run multiple instances when your box has more than 3GB running in
32-bit mode with PAE. Regarding the numbers in top, that would be interesting to see. It could be a
quirk with the numbers themselves, or it could be that theres some exception going on but in general
your understanding is correct processes cant use more than 3GB.
Regarding the 1GB not being shown in VIRT, its because the kernel accounting ignores the kernel
space. Its just a design issue why worry about it since its there for every process? People would be
shocked to see /bin/ls running with 1GB of virt space
71. maverick on April 29th, 2009 12:03 am
great post.. keep up the good work.. have a doubt regarding the memory mapped area for shared
libraries..it starts 040000000. Does it grow upwards or downwards ? I remember it grows upwards. In
your both figures, its drawn differently.
72. Narayanan on April 30th, 2009 3:27 am
Hi ,
I ve doubt regarding malloc allocting memory. How does malloc stores information about the size of
the pointer as free uses only pointer variable as argument and not the size. can u explain which part of
address space it is stored..?
15 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
Thanks in advance
73. Keith Johnson on April 30th, 2009 9:14 am
Awesome post! Indeed, memory management cannot be overlooked.
74. Gustavo Duarte on May 3rd, 2009 9:44 pm
@maverick: in x86 Linux it grows as shown in the diagrams, but this varies by CPU architecture and
kernel.
@Narayanan: Malloc does its own house keeping to know how much was allocated to each pointer.
The best place to check this out is reading the libc source code for malloc and free.
@Keith: thanks!
75. Quick Note on Diagrams and the Blog My Site! on May 14th, 2009 4:41 pm
[...] colors hold from the earliest post about memory to the latest. This convention is why the post
about Intel CPU caches shows a blue index for the virtually [...]
76. Brian on June 4th, 2009 8:26 am
Thanks for this post Gustavo. I have a question, though.
Im mainly a sysadmin, not a low-level developer, but I need to understand this stuff for low-level
debugging at the system level. Near the top of this post, you mention ring 2 or lower as if we should
all just know what that even means, and Im sorry to say that I do not. Could you point me to a doc
thatll explain that, or could you expand on what this notion of rings relates to?
Thanks all of your posts are top notch.
77. Gustavo Duarte on June 8th, 2009 9:33 am
Hi Brian,
Here you go: http://duartes.org/gustavo/blog/post/cpu-rings-privilege-and-protection
cheers
78. Peter on June 15th, 2009 2:24 pm
Dear Gustavo,
Could you send the list of references you use to write Linux internals stuff ?
If you already posted it, please, let me know the url of them.
Best,
Peter.
16 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
17 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
18 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
Thanks,
-Mukesh Chauhan
90. Gaurab on November 21st, 2009 11:42 am
Useful post.
How do you explain this segment:
08049000-0804a000 rp 00000000 08:05 276412 /home/Linux/MemoryMgmt/printMem
where the permission on this segment is read-only and printMem is the c code ? Text are read-execute
right ? So, only read perm ?
91. Kevin Rodrigues on December 8th, 2009 2:34 am
I just happened to view your post when I was searching for the structure of a c program in memory.
You have provided a lot of information which is quite rare on the Internet. Thanks!
92. Amit Pande on December 22nd, 2009 1:47 am
Great articleno other links I googled explains fundamentals better than this ! Not sure how come
Google did not rank it higher
93. Funktionsweise eines Betriebssystems | duetsch.info - GNU/Linux, Open Source,
Softwareentwicklung, Methodik und Vim. on December 28th, 2009 6:20 am
[...] Anatomy of a Program in Memory [...]
94. kreena on December 30th, 2009 1:25 am
Hi
This is very nice blog I ever came across !!!
The contents are very clear and written in very simple terms.
I want to ask you, how can I change the address space layout from classic to flexible layout
95. divkis on January 4th, 2010 11:18 pm
Hi, great post overall but I dont see the addresses of all segments shown by examining the maps i.e
/proc/pid/maps. I see the stack, heap and mapped .sos but not the other segments. The maps for my
firefox is shown below. Mine is a debian system with 2.6.32.2 SMP kernel.
Is there any other way to see the complete layout of a process in memory?
08048000-0804f000 r-xp 00000000 08:01 1893676 /usr/lib/xulrunner-1.9/xulrunner-stub
0804f000-08050000 rw-p 00006000 08:01 1893676 /usr/lib/xulrunner-1.9/xulrunner-stub
0810c000-0c599000 rw-p 00000000 00:00 0 [heap]
ad6ff000-ad700000 p 00000000 00:00 0
ad700000-adf00000 rw-p 00000000 00:00 0
19 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
20 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
21 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
22 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
23 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
24 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
25 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
26 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
27 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
28 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
I did a hexdump >>hexdump -C in my linux machine on my elf(executable) and I was able to trace
out the different sections and segments with the hexdump >>readelf -x .text . Now the hexdump from
the readelf utility has addresses associated with them like this:
008048540 ffc70424 74870408 e8e3feff ffe8e300 $t..
008048550 0000b8a4 8704088d 54242f89 54240489 ..T$/.T$..
008048560 0424e8b9 feffff0f b644242f 0fbec88b .$.D$/.
008048570 5424248b 44242889 4c240889 54240489 T$$.D$(.L$..T$..
I want to know exactly how the kernel associates each byte in the elf file to an address like
008048540. Please help clarify things, I dont believe in magic. I also read that section .symtab is not
included in the elf executable file, why is it that the readelf utility can perform a hexdump on it like this
>>readelf -x .symtab
000000000 00000000 00000000 00000000 00000000 .
000000010 00000000 34810408 00000000 03000100 .4..
000000020 00000000 48810408 00000000 03000200 .H..
000000030 00000000 68810408 00000000 03000300 .h..
101. Stef on April 19th, 2010 4:20 am
Salut Gustavo,
Thanks for your pages, they are great.
Being knowledgeable in the topic, there is however a tough one I was not able to solve myself. Maybe
you or someone reading this page can cast some light on it?
I recently installed openSUSE 11.2 32 bits and Kubuntu 9.10, both running Linux kernel 2.6.31.
I dont understand why cat /proc//maps (related to the top command here for example) returns 4 lines
per shared libraries (for some, not all the usual 3 lines then).
3 lines, like in older kernel (2.6.28, ), makes sense: bss, data and text segments. In some kernels I
noticed also two entries only per shared library (bss merged with data, or data only? That makes sense,
at least)
However, 4 entries (!), one being a page of rights p (cannot be read, written or executed) seems
very odd to me. I get the same results on my SUSE and Kubtuntu, so hence no bug. But what then?
There is nothing much in the ELF format that give me any hint.
An exemple for libncurses.so.5.6 (related to top):
b76ab000-b76e1000 r-xp 00000000 08:02 127570 /lib/libncurses.so.5.6
b76e1000-b76e2000 p 00036000 08:02 127570 /lib/libncurses.so.5.6
b76e2000-b76e4000 rp 00036000 08:02 127570 /lib/libncurses.so.5.6
b76e4000-b76e8000 rw-p 00038000 08:02 127570 /lib/libncurses.so.5.6
Stphane
102. Sudheer on May 24th, 2010 8:12 am
29 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
Hi Guru,
A basic question.
Is there any difference in generation of logical addresses for a program in linux OS and windows OS?
103. Graphics Designer Middlesex on June 4th, 2010 11:45 am
When i was studying my diploma there was a subject called COA which has this topic at that time i
didnt get it and this time also. (Dont mind author bcoz my knowledge in hardware functionality is
very poor) But definitely this post will useful for tech savvy guys
104. Shobhit Gupta on June 30th, 2010 8:48 pm
Wow, what a great article.
I was searching for exactly this kind of (easy to understand) detailed information on Process Address
Space.
I couldnt help not thank you for this article.
Thanks a lot,
Shobhit
105. JAT on July 1st, 2010 5:05 am
Excellent Work
106. Super on July 6th, 2010 7:35 pm
Pretty cool, thank you for your great job! It really helps me a lot.
107. chaitanya on July 9th, 2010 10:57 am
Thanks for the in-detailed article
108. Anty on July 10th, 2010 1:26 am
Pretty Cool, THX very much
109. nandu on July 29th, 2010 5:39 am
Really very informative articles on Linux memory internals.
If you write one more article relating Virtual memory,Kernel memory with pysical memory(RAM),
covering how the kernel gets loaded in RAM and stored, how the remaining RAM space is used for
this memory mapping, really this will give great insight for beginners,
Thanks,
Nandu
110. Chris on August 10th, 2010 12:56 am
I think you mean always a 4KB block of memory addresses instead if always a 4GB block of
memory addresses.
13/01/2014 04:16 p.m.
30 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
31 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
119. How the Linux kernel manages your memory DEEPAK.IO on May 6th, 2011 6:29 pm
[...] examining the virtual address layout of a process, we turn to the kernel and its mechanisms for
managing user memory. Here is gonzo [...]
120. saurin on May 11th, 2011 3:56 pm
I have a question about the linear to physical memory translation
According to my understanding,
Application run time address itself contains the PGD offset, PTE offset and page offset.
swapper_pg_dir is the PGD and located in linux kernel image, and linux kernel build the page table for
4GB memory.
Question is:
When MMU translate the linear address to physical address it requires Page Global directory table and
Page Table array, from where it gets that? because PGD and PTE arrays are located itself in physical
memory
121. Harold Wang on May 25th, 2011 7:55 am
Amazing Job! Thank you!
122. Raju on May 30th, 2011 10:59 pm
Hi:
I was going through your link posted
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
I am having some doubts regarding the Stack segments , does we never has Segmenation fault in Linux
??
does at time of Stack space on demand stack offset()/mmap offset()
comes in picture , can you give me some example how to implement it ??
123. Pravin on July 3rd, 2011 8:27 am
Thanks heaps!
124. PHP 64- ? ! ::
on July 12th, 2011 11:07 pm
[...] [...]
125. Build your own operating system | scienceasm on July 21st, 2011 2:48 am
[...] how it protects processes from each other. You should also get the idea about how the OS lays out
executables and shared libraries within the process address space and how it creates shared
memory regions. Two core abstractions of every modern OS [...]
32 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
126. Tienes dudas con la memoria? | Blog-AitorPazos on July 25th, 2011 8:04 am
[...] http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory This entry was posted in
Linux by Aitor Pazos. Bookmark the permalink. [...]
127. Vaibhav Jain on September 1st, 2011 1:28 pm
This is an awesome article!!
But I just have a small query. You have mentioned that the
string that the pointer gonzo points to Gods own prototype is in text segment and is
read-only.But then what if I try to change the string by assigning some string to *gonzo like *gonzo =
my string. Will it throw a segmentation fault?
128. David on September 15th, 2011 8:47 am
Great post, (with the virtual address layout) why is [00, 008048000) left unmapped? Is it a
no-touching region? Any reason?
129. Mars on September 22nd, 2011 7:43 pm
Hi Gustavo Duarte
Thanks for this great article. May I translate it to Traditional Chinese?
I think this will help more programmers in Taiwan understand this concept.
Thanks again.
130. Anatomy of a Program in Memory : Gustavo Duarte | FRANCESCO DI FUSCO on October 31st, 2011
1:43 am
[...] Anatomy of a Program in Memory : Gustavo Duarte. Share
this:TwitterFacebookStumbleUponPrintEmailLinkedInLike this:LikeBe the first to like this post. This
entry was posted in Linux, Operating Systems by francescodifusco. Bookmark the permalink. [...]
131. Ramachandra on November 15th, 2011 3:16 am
Wonderful article It helped me to regain my position in Indias 3rd largest IT company.
132. itachi on November 16th, 2011 1:17 am
thanks for the article.. i am reading ages after you wrote it.. but i am glad i did.. ll go through other
posts of yours.. really informative!!
133. From 090 to 0x4c454554, a journey into exploitation Mr.Anubis's Blog on November 29th, 2011
7:23 pm
[...] Anatomy of a program in memory [...]
134. Anon on December 7th, 2011 6:32 pm
Great article! Thanks.
33 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
I have a query. The figure you have shown is when you have a single process. When there are say 2
processes, how will the memory layout be? I understand as below from top of memory to bottom
1)kernel space(1 gb) same
2) all other sections gets split for p1, p2 say of size 3gb/2
Please correct me if i am wrong.
135. Markus on January 2nd, 2012 2:20 am
Hi Gustavo!
Thanks for a great article.
I am wondering if you could explain what you mean with the following:
The text segment also maps your binary file in memory, but writes to this area earn your program a
Segmentation Fault. This helps prevent pointer bugs
Does it mean that the text segment contains code to make an additional mapping of the entire binary
file (in addition to the BSS and data segments as explained earlier in the article)?
Also, how do this prevent pointer bugs?
Brs,
Markus
136. kishor kunal on January 17th, 2012 12:21 am
very nice .thank u dude.
137. Vivek kumar on February 14th, 2012 6:48 am
Hi,
Thanks for great explanation, Its helped me to start it once again as I had left this topic.
Can you please let me know one thing as it will help me to move further.
Anyway, here is the standard segment layout in a Linux process:
Is the OS create same layout for every process. Or there is a single Heap/Memory for all processes.
Thanks again for your post.
138. ()-ld_brk_pointbrk-Sigma on April 9th, 2012 6:05 am
[...] http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory [...]
139. CS:APP bufbomb | Chaoswork on April 13th, 2012 7:17 am
[...] blog:http://duartes.org/gustavo
/blog/post/anatomy-of-a-program-in-memory,
4G
34 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
linux
swap [...]
140. How Does a Startup Out-recruit Google How Google Indexes the Web Code Retreat and What Was
Learnt in 45 Minutes Flipkart Slideshow Banner Anatomy of a Program in Memory What Is and Why
Octopress ? Welcome ! CSS Tips on April 28th, 2012 1:48 am
[...] Memory management is the heart of operating systems; it is crucial for both programming and
system administration. Gustavo Duarte, duartes.org/gustavo/blog/post/ [...]
141. How Does a Startup Out-recruit Google How Google Indexes the Web Code Retreat and What Was
Learnt in 45 Minutes Flipkart Slideshow Banner Anatomy of a Program in Memory What Is and Why
Octopress ? Welcome ! CSS Tips on April 28th, 2012 3:15 am
[...] Here is something that was taught very poorly in the OS class that I took as an undergraduate
student Memory management is the heart of operating systems; it is crucial for both programming and
system administration. Gustavo Duarte, duartes.org/gustavo/blog/post/ [...]
142. Abhinav on May 2nd, 2012 7:44 pm
Its an informative post, but there is one thing that is really bothering me.
I dont understand if the sections (text,data,bss) are
(i) all created at once by the OS & then chunks out of them is provided to the needing process, or does
(ii)each process has its own unique sections whose actual physical location may vary?
If the answer is (i) then how come a process has linear virtual address space?
Please provide some explanation.
143. Allen on May 23rd, 2012 4:29 pm
Thanks! Provided exactly what I was looking for
144. sanjay on June 7th, 2012 11:42 am
Gustavo,
it is really useful article for me great post .. would like to read your posts in sequence for
understanding the internals
I would like to know more on the memory mapping part mentioned here if you can suggest any post
/ direct me to your post, it would be helpful to me
Thanks again Gustavo for your explanation here
- Sanjay
145. Blog Archive on June 9th, 2012 2:26 am
[...] http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
[email protected] /* */ [...]
35 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
36 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
[...] (excluding some embedded ones) use virtual memory mapping. Check out this link for an
overview: Anatomy of a Program in Memory : Gustavo Duarte. Google "linux process memory layout"
for more examples and info of how Linux does it. [...]
156. nadji on November 30th, 2012 1:58 pm
it is the better tutorial thank you
157. leo kirotawa on January 10th, 2013 11:19 am
Great blog and article =). Im trying find a good material about that. Thanks a lot!
158. abhishek on January 12th, 2013 12:53 pm
I have some confusion with respect to what you posted
you mention Each process in a multi-tasking OS runs in its own memory sandbox. This sandbox is the
virtual address space, which in 32-bit mode is always a 4GB block of memory addresses.
Does that mean on a system with 4GB RAM only one process is running at a time?
because the same is reflected by the diagram in which firefox is running in occupying the blue part of
diagram.
Also what do stack and heap contain in case of a running program?
159. Kavitha Srinivas on February 1st, 2013 4:04 am
Hi Gustavo,
Thank you again for the wonder article, I have read you article on boot sequence for linux as well.
I have a doubt ,
1) What is Virtual Memory?
Some say that virtual memory is nothing but the harddisk and some say no its not harddisk. When we
run any program we get the virtual address where is this address actually present?
If Virtual memory is Hardisk itself, then harddisk is format with some filesystem right? how and which
program actuall helps processor to access the harddisk.
Thanks and Regards
Kavitha
160. Kavitha Srinivas on February 4th, 2013 3:32 am
Hi Gustavo,
Thank you again for the wonder article, I have read you article on boot sequence for linux as well.
I have a doubt ,
1) What is Virtual Memory?
Some say that virtual memory is nothing but the harddisk and some say no its not harddisk. When we
run any program we get the virtual address where is this address actually present?
If Virtual memory is Hardisk itself, then harddisk is format with some filesystem right? how and which
program actuall helps processor to access the harddisk.
Thanks and Regards
13/01/2014 04:16 p.m.
37 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
Kavitha
161. Anatomy of a Program in Memory | Arun's Blog on March 1st, 2013 3:29 am
[...] article on how a programs reside in the memory at runtime Anatomy of a Program in Memory
Share this:ShareEmailLike this:Like Loading This entry was posted in Technical on 1 Mar, 2013 [...]
162. Program in memory : An insiders look | Kapil Jain on March 1st, 2013 4:17 am
[...] this Article which presents a very good picture of how a program resides in memory while
executing. Highlights [...]
163. Mayank on March 8th, 2013 2:21 am
Very well explained, To know more about memory heap I find this thread very helpful :
http://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap#79936 (See
comment from guy named Martin Liversage)
164. Karthik on March 21st, 2013 7:06 am
Superb post. Have a question though, when running a function multi threaded each thread has to have a
separate stack. Does it mean in the address space there are multiple active stacks ?
165. Pratik on March 28th, 2013 8:06 pm
Hi Gustavo,
I understood that user and kernel stacks are two different things even if they are refer to the same
process. But my question is, does kernel has its own separate stack which can be used for user
independent processing, i.e. scheduler activities. I think, scheduler is not accessed by any system call or
any user space process. But scheduler must have stack for its own processing. So which is this stack
used by scheduler?
166. Ivan Stanev on April 15th, 2013 2:52 pm
Hi Gustavo,
What resides between addresses 000000000 and 008048000 (the small white space at the bottom of
your diagrams)? Its the only thing I couldnt understand
Regards
167. Sham on May 4th, 2013 7:48 pm
Hello Gustavo
I am dying to get such details for x64 environment.
168. Memory Organization in C++ | BlogoSfera on May 6th, 2013 11:57 pm
[...] http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory [...]
169. Memory Organization in C++ [closed] | BlogoSfera on May 7th, 2013 6:57 am
13/01/2014 04:16 p.m.
38 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
39 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
Email Address(required)
40 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
Website
Find It
Recently Written
Added Best Of Page, Back to Writing
Page Cache, the Affair Between Memory and Files
The Thing King
How The Kernel Manages Your Memory
Quick Note on Diagrams and the Blog
Anatomy of a Program in Memory
Getting Physical With Memory
Programming and the Recession
Daddy, why does it smell like fire?
Cache: a place for concealment and safekeeping
Categories
Business
CompSci
Culture
Internals
Linux
Meta
Personal
Productivity
Programming
Security
Software Illustrated
Sysadmin
Monthly Archives
13/01/2014 04:16 p.m.
41 de 41
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
December 2010
February 2009
January 2009
December 2008
November 2008
October 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
Copyright 2008 Gustavo Duarte Using Cangao, based on Dropshadow theme by Brian Gardner