-
Gustavo DuarteSoftware, computers, and business.
HomeAboutArticlesSubscribe
Anatomy of a Program in MemoryMemory management is the heart of
operating systems; it is crucial for both programming and
systemadministration. In the next few posts Ill cover memory with
an eye towards practical aspects, but withoutshying away from
internals. While the concepts are generic, examples are mostly from
Linux and Windowson 32-bit x86. This first post describes how
programs are laid out in memory.
Each process in a multi-tasking OS runs in its own memory
sandbox. This sandbox is the virtual addressspace, which in 32-bit
mode is always a 4GB block of memory addresses. These virtual
addresses aremapped to physical memory by page tables, which are
maintained by the operating system kernel andconsulted by the
processor. Each process has its own set of page tables, but there
is a catch. Once virtualaddresses are enabled, they apply to all
software running in the machine, including the kernel itself. Thus
aportion of the virtual address space must be reserved to the
kernel:
This does not mean the kernel uses that much physical memory,
only that it has that portion of address spaceavailable to map
whatever physical memory it wishes. Kernel space is flagged in the
page tables as exclusiveto privileged code (ring 2 or lower), hence
a page fault is triggered if user-mode programs try to touch it.
InLinux, kernel space is constantly present and maps the same
physical memory in all processes. Kernel codeand data are always
addressable, ready to handle interrupts or system calls at any
time. By contrast, themapping for the user-mode portion of the
address space changes whenever a process switch happens:
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
1 de 41 13/01/2014 04:16 p.m.
-
Blue regions represent virtual addresses that are mapped to
physical memory, whereas white regions areunmapped. In the example
above, Firefox has used far more of its virtual address space due
to its legendarymemory 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 todo 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 abovewere exactly the same
for nearly every process in a machine. This made it easy to exploit
securityvulnerabilities remotely. An exploit often needs to
reference absolute memory locations: an address on thestack, the
address for a library function, etc. Remote attackers must choose
this location blindly, counting onthe fact that address spaces are
all the same. When they are, people get pwned. Thus address
spacerandomization has become popular. Linux randomizes the stack,
memory mapping segment, and heap byadding offsets to their starting
addresses. Unfortunately the 32-bit address space is pretty tight,
leaving littleroom for randomization and hampering its
effectiveness.
The topmost segment in the process address space is the stack,
which stores local variables and functionparameters in most
programming languages. Calling a method or function pushes a new
stack frame onto thestack. The stack frame is destroyed when the
function returns. This simple design, possible because the
dataobeys strict LIFO order, means that no complex data structure
is needed to track stack contents a simple
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
2 de 41 13/01/2014 04:16 p.m.
-
pointer to the top of the stack will do. Pushing and popping are
thus very fast and deterministic. Also, theconstant 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 pagefault that is
handled in Linux by expand_stack(), which in turn calls
acct_stack_growth() to check whetherits appropriate to grow the
stack. If the stack size is below RLIMIT_STACK (usually 8MB), then
normally thestack grows and the program continues merrily, unaware
of what just happened. This is the normalmechanism whereby stack
size adjusts to demand. However, if the maximum stack size has been
reached, wehave a stack overflow and the program receives a
Segmentation Fault. While the mapped stack area expandsto 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 whiteabove, might be valid. Any
other access to unmapped memory triggers a page fault that results
in aSegmentation Fault. Some mapped areas are read-only, hence
write attempts to these areas also lead tosegfaults.
Below the stack, we have the memory mapping segment. Here the
kernel maps contents of files directly tomemory. Any application
can ask for such a mapping via the Linux mmap() system call
(implementation) orCreateFileMapping() / MapViewOfFile() in
Windows. Memory mapping is a convenient andhigh-performance way to
do file I/O, so it is used for loading dynamic libraries. It is
also possible to create ananonymous memory mapping that does not
correspond to any files, being used instead for program data.
InLinux, if you request a large block of memory via malloc(), the C
library will create such an anonymousmapping instead of using heap
memory. Large means larger than MMAP_THRESHOLD bytes, 128 kB by
defaultand adjustable via mallopt().
Speaking of the heap, it comes next in our plunge into address
space. The heap provides runtime memoryallocation, 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 affairbetween
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 runtimewithout kernel
involvement. Otherwise the heap is enlarged via the brk() system
call (implementation) tomake room for the requested block. Heap
management is complex, requiring sophisticated algorithms
thatstrive for speed and efficient memory usage in the face of our
programs chaotic allocation patterns. The timeneeded to service a
heap request can vary substantially. Real-time systems have
special-purpose allocators todeal 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 storecontents for static (global)
variables in C. The difference is that BSS stores the contents of
uninitialized staticvariables, 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 inthe BSS.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
3 de 41 13/01/2014 04:16 p.m.
-
The data segment, on the other hand, holds the contents for
static variables initialized in source code. Thismemory area is not
anonymous. It maps the part of the programs binary image that
contains the initial staticvalues given in source code. So if you
say static int cntWorkerBees = 10, the contents of
cntWorkerBeeslive in the data segment and start out as 10. Even
though the data segment maps a file, it is a private memorymapping,
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 pointergonzo 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
likestring literals. The text segment also maps your binary file in
memory, but writes to this area earn yourprogram a Segmentation
Fault. This helps prevent pointer bugs, though not as effectively
as avoiding C in thefirst 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
hasits own area in the mmap segment, and dynamic libraries have
extra areas similar to BSS and data. The nextpost 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 thatsnot the case,
Linux reverts back to the classic layout shown below:
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
4 de 41 13/01/2014 04:16 p.m.
-
Thats it for virtual address space layout. The next post
discusses how the kernel keeps track of these memoryareas. Coming
up well look at memory mapping, how file reading and writing ties
into all this and whatmemory usage figures mean.
January 27, 2009 at 12:34 am | Filed Under Internals, Linux,
Software IllustratedSubscribe to blog
184 Comments
Comments184 Responses to Anatomy of a Program in Memory
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!
1.
Gustavo Duarte on January 27th, 2009 12:55 am
@JP: sweet, glad it came at a good time. Youre welcome!
2.
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 onmemory management about processes. Can
you suggest me any books or other documentation?
3.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
5 de 41 13/01/2014 04:16 p.m.
-
Thanks!
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_ inpainstaking 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 eventuallymaybe have a short Intro
to the Linux Kernel document online. However this is subject to my
workschedule and so on.
4.
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
docyou suggest me and keep reading your blog
thanks!
5.
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 yourother posts really
informative and easy to read. Big + goes for the diagrams, they
help clarify on a lotof points. Keep up the good work!
6.
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.
7.
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?
8.
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 alsorandomized. And in Linux
string literals such as char *blah = hello there; will be stored in
an ELFsection called .rodata. Rarely is constant data such as
strings held in .text, but it does happen. Goodpost though, I like
the graphics.
9.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
6 de 41 13/01/2014 04:16 p.m.
-
gatechman on January 27th, 2009 6:56 am
Great Post!
10.
Programming links | GreenwaysRoad Blog on January 27th, 2009
7:06 am
[...] Anatomy of a program in memory [...]
11.
Jose V. on January 27th, 2009 7:12 am
Gustavo:
Excellent article, Ive been looking for a post like this for a
long time. By the way, this made it to thefront page of reddit, so
brace for incoming traffic.
J.V.
12.
el_bot on January 27th, 2009 8:05 am
Good post!Only for completeness, can you include the programs
parameters? I think they go in the bottom of thestack, but Im not
sure. In any case, of course, they are put by the kernel when a
execXX in called.
Saludos
13.
raja on January 27th, 2009 8:20 am
thank you.very informative and refreshing.looking forward to the
next post
14.
Daily Links #18 | CloudKnow on January 27th, 2009 9:16 am
[...] Anatomy of a Program in Memory [...]
15.
Sushant Srivastava on January 27th, 2009 9:38 am
Thank you for this wonderful post.
16.
Gustavo Duarte on January 27th, 2009 9:40 am
Thank you all for the feedback!
@web dev: The kernel is not really using that much memory
physical though, it simply has that virtualrange available to
itself to map whatever physical memory it wishes. Thanks for the
question though I clarified this in the post.
Both the Linux and Windows kernel are extremely well built. Its
hard to find areas where one reallyhas an edge, imho. Two
outstanding pieces of software.
@numerodix: You know, this tightness of the address space is a
sort of recent phenomenon. When thekernels were designed, 2 or 3GB
seemed like a lot So partially its an evolutionary artifact, one
that
17.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
7 de 41 13/01/2014 04:16 p.m.
-
is fixed by 64-bit address spaces.
But also, it is good for performance to give the kernel an ample
window into memory. I think the nextcouple posts should clarify why
this is.
@Reader1: thanks for the corrections. Ill add the heap
randomization to the post. Regarding ELFsections, I thought about
them, but Im always balancing what to include in these blog posts.
I try hardto keep it crisp, covering one area well, but without
dumbing anything down. But theres so muchinterconnected stuff, its
not always clear where to put the line. I think Im going to leave
ELF sectionsout for now though.
@Jose: thanks for the heads up
@el_bot: This is one similar to ELF sections above. The tradeoff
between conciseness andcompleteness. Im planning a post covering
the stack in detail, and talking about buffer overflows, andI think
thatd go in well there.
Carlos on January 27th, 2009 10:24 am
Thanks for the post, it is very informative. Can you tell me
what software do you use to creategraphics?
18.
Gustavo Duarte on January 27th, 2009 10:25 am
I use Visio 2007 for the diagrams. Cheers.
19.
Chaitanya Gupta on January 27th, 2009 10:33 am
As everyone has said, great post. I am looking forward to your
follow up posts. Thanks.
20.
emit on January 27th, 2009 11:09 am
I love your diagrams w/ the subtle gradients. What did you use
to create them?
21.
emit on January 27th, 2009 11:10 am
oops I didnt see #19 reply. ok so it was visio
22.
NoName on January 27th, 2009 12:25 pm
This blog includes very interesting articles. Continue your good
work and never give up!
23.
tek on January 27th, 2009 2:00 pm
Excellent and informative post
24.
vs on January 27th, 2009 2:42 pm
Ive been reading your posts for a while now, but I just wanted
to take a moment to actually write acomment thanking you. These are
some really informative posts you write. You should considerwriting
a book on the internals of systems level software.
25.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
8 de 41 13/01/2014 04:16 p.m.
-
David on January 27th, 2009 4:35 pm
Nice post. Very clear. Ill keep reading you.
26.
dev on January 27th, 2009 4:51 pm
Nice Post. Well written and concise. Looked at your Physical
with memory post and its good too.
27.
John on January 27th, 2009 6:33 pm
You mentioned, Each thread in a process gets its own stack., but
I thought in linux, a thread is reallyjust another process that
happens to share certain things with other processes. Could you
clear up myconfusion?
28.
links for 2009-01-27 at DeStructUred Blog on January 27th, 2009
7:05 pm
[...] Anatomy of a Program in Memory : Gustavo Duarte (tags:
windows reading linux programmingkernel management memory)
[...]
29.
Sesh on January 27th, 2009 9:52 pm
I will try to thank you in a simple way: for a long time doubts
about where string literals stay inmemory would linger in my mind
but so far I was not able to find any easy explanation anywhere.
Thispost makes it clear now.
Thank you very much. Cant wait for the next articles in this
series.
30.
Gustavo Duarte on the Anatomy of a Program in Memory on January
27th, 2009 10:13 pm
[...] his latest post, Anatomy of a Program in Memory, Gustavo
Duarte explains beautifully the way inwhich programs are laid out
in memory. He explains [...]
31.
Raam Dev on January 27th, 2009 10:19 pm
I just finished an Introduction to C Programming class and this
beautifully written post is a godsend forhelping me further my
understanding of memory management.
Thank you so much!
32.
Gustavo Duarte on January 28th, 2009 12:20 am
First off, thank you all for the feedback!
It is great to hear that the post helped out a little bit.
Contributing to the community is one of the majorreasons I write
this stuff, though it doesnt hurt that its fun.
@vs: the idea of a book does surface in the comment threads from
time to time. I see a few issuesthough: 1) I want to keep the
content free, no matter what; 2) the color would be gone in a
normalbook; 3) the links would be gone.
Lately Ive been thinking about maybe collecting all the stuff
once theres enough, and having anonline book of sorts. Then maybe
make color prints for a small fee if people wanted hard copies
(I
33.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
9 de 41 13/01/2014 04:16 p.m.
-
wouldnt mind making money on these).
I really had no idea where this blog would go, though now its
becoming a bit clearer. So yea, Immunching on it.
@John: you are correct. Basically the set of threads in a thread
group share all the memory regionsexcept for the stack and
thread-local-storage. Within the kernel, threads are represented
with the samedata structure used for processes, task_struct, so
again you are correct.
Does this help clear it up? I could dig up the relevant links to
kernel code if youd like to see the stuffin action. Let me
know.
links for 2009-01-28 boblog on January 28th, 2009 3:03 am
[...] Anatomy of a Program in Memory Memory management is the
heart of operating systems; it iscrucial for both programming and
system administration. In the next few posts Ill cover memory
withan eye towards practical aspects, but without shying away from
internals. While the concepts aregeneric, examples are mostly from
Linux and Windows on 32-bit x86. This first post describes
howprograms are laid out in memory. (tags: windows reference
programming hardware) [...]
34.
kgas on January 28th, 2009 7:11 am
Right away I am book marking your site for further reading. Nice
articles. This will be much helpful tonewbie and those who wants to
learn about computers and students. Keep it up!
35.
John on January 28th, 2009 7:27 am
@Gustavo, thank you so much. All is clear. I used to have a book
on the linux kernel where the codewas also annotated, but I
unfortunately just dont have the time, so your excellent posts and
articles aregreatly appreciated!
36.
Ulver on January 28th, 2009 7:30 am
Interesting arcticle, Very didactly and with figures!! xD well
being a litle bit serious, i think that isvery clear and simply to
explain the concepts, follow in this way !
pd: for more linux kernel understading, in viewly way it will be
use kernel profiling, aka /proc/profile & kerneltop very useful
to see internal functions and the corresponding behavior of
that.
cheers !
37.
Chanux on January 28th, 2009 7:54 am
Great post. I want learn the art of writing great articles like
this. I was looking for a point to get in tokernel level stuff.
There wont be any better source than this.
Subscribed to RSS. ( Looking for Twitter )
38.
Fab on January 28th, 2009 9:39 am
Great article !
39.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
10 de 41 13/01/2014 04:16 p.m.
-
Drawing are neat ! What soft do you use for them ?
Ben Fowler on January 28th, 2009 3:39 pm
Once again, great article! I think this blog is one of the best
website Ive seen on introductory OSinternals Ive seen yet. Anything
beyond that, I need to start reading my copy of Hennessey
andPatterson
I thought Id spotted a typo in one of the diagrams, but no it
turns out youve really shown attentionto detail in these articles.
Nice work.
40.
Quick Note on Diagrams and the Blog : Gustavo Duarte on January
28th, 2009 6:25 pm
[...] colors hold from the earliest post about memory to the
latest. This convention is why the postabout Intel CPU caches shows
a blue index for the virtually [...]
41.
gsempe on January 29th, 2009 6:13 am
Very clear, informative, nice post.Good job.
42.
JP on January 29th, 2009 7:49 pm
If you decide to do a small online book with such great content
on all aspects of OS management, I willgladly buy it!
43.
ken on January 30th, 2009 7:46 pm
wow thats informative,got lost a bit into it but have bookmarked
to come back to.good work
44.
vlad on February 1st, 2009 9:52 pm
Great article Thanks for the effort of keeping things simple and
informative!
45.
satmeet on February 1st, 2009 10:17 pm
BOOKMARKED..!!awaiting your next posts!!Thanks
46.
IvanM on February 2nd, 2009 2:46 am
Very clear explanation of memories either phyisical or
virtualThanky you again!
47.
Prabhu on February 2nd, 2009 6:03 am
Hi Gustavo,
The explanation was very clear and informative. Thanks.One
rquest. If you could explain in the same lucid way how a program
wriiten in high level language ,say C, gets compiled , what are
symbols, how shared files gets linked , how addresses are
determined
48.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
11 de 41 13/01/2014 04:16 p.m.
-
when loaded into memor and such nitty gritty details, it would
be great!
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 from2000, not sure how much has
changed since. Im going to add this to my write queue, though I
have noidea when the post would actually come out
49.
bekars on February 3rd, 2009 12:29 am
Great works, Thank you
50.
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 formanaging user memory. Here is
gonzo [...]
51.
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 Heapsystem. Keep writing. Thanks a lot
for sharing these helpfull contents.
52.
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 isrepresented in memory [...]
53.
Nix on February 5th, 2009 7:01 am
Another excellent series on linkers is Ian Lance Taylors
20-article series starting near the bottom ofand proceeding onwards
for several pages.
54.
Nix on February 5th, 2009 7:01 am
Oh, curses. Fixed link to the linkers series start
55.
Gustavo Duarte on February 5th, 2009 9:25 am
@Nix: great link, thanks!
56.
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) [...]
57.
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 stackareas located with respect to each other?
e.g if there are two threads in a process T1 & T2 where
wouldtheir stacks start and end in the memory. The second question
is similar. Does each thread has two
58.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
12 de 41 13/01/2014 04:16 p.m.
-
stacks one for user mode and one for kernel mode?
macosx on February 8th, 2009 10:34 pm
Great jobs.keep going on and publishing more articles
59.
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 workthese past few days. Can you drop me
an email so that I can let you know when Ive replied here?
60.
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 Windowsonly.
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 afunction that prints the address of a local variable. If
you do a loop of 10 or so the pattern shouldbecome clear. I found
two relevant posts;
http://blogs.msdn.com/oldnewthing/archive/2005/07/29/444912.aspxhttp://software.intel.com/en-us/articles/adjusting-thread-stack-address-to-improve-performance-on-intel-xeonr-processors/
Regarding the second question, YES, threads have two stacks: a
large one for user mode (1MB bydefault it looks like) and a tiny
one for kernel mode (just a few kilobytes, 12k for x86). The
kernelstack is kept in kernel-mode data structures and cant be
touched from user mode.
Hope this helps.
61.
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 allyour articles on your
blog.Greate Job And Execllent Articles~~~
62.
Ya-tou & me Blog Archive How The Kernel Manages Your Memory
on February 19th, 2009 1:43am
[...] examining the virtual address layout of a process, we turn
to the kernel and its mechanisms formanaging user memory. Here is
gonzo [...]
63.
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 dememoria alrededor de un
[...]
64.
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
65.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
13 de 41 13/01/2014 04:16 p.m.
-
than 3gb in a default running linux system, since 1gb is
reserved for the kernel, is this true or not? Iremember that Ive
seen processes that are using more than 3gbm as far as top is
concerned, but I couldbe wrong (32bit system). Also for example,
for top, why isnt the 1gb, reserved for the kernel, added inthe
VIRT space?
Justin Blanton | Anatomy of a program in memory on March 12th,
2009 10:41 pm
[...] Anatomy of a program in memory. [...]
66.
birumut on March 18th, 2009 11:13 am
thank you very much, in fact it is very useful for me
67.
Nagareddy on March 20th, 2009 12:59 pm
Very useful and comprehensiv , to point..
How do you know windows size limits?
68.
Gustavo Duarte on March 23rd, 2009 6:40 pm
@Nagareddy: which size limits? But regardless of which limits,
they probably are either from theWindows Internals book, Windows
header files, or Intel literature
69.
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 thememcached folks tell you to run multiple
instances when your box has more than 3GB running in32-bit mode
with PAE. Regarding the numbers in top, that would be interesting
to see. It could be aquirk with the numbers themselves, or it could
be that theres some exception going on but in generalyour
understanding is correct processes cant use more than 3GB.
Regarding the 1GB not being shown in VIRT, its because the
kernel accounting ignores the kernelspace. Its just a design issue
why worry about it since its there for every process? People would
beshocked to see /bin/ls running with 1GB of virt space
70.
maverick on April 29th, 2009 12:03 am
great post.. keep up the good work.. have a doubt regarding the
memory mapped area for sharedlibraries..it starts 040000000. Does
it grow upwards or downwards ? I remember it grows upwards. Inyour
both figures, its drawn differently.
71.
Narayanan on April 30th, 2009 3:27 am
Hi ,
I ve doubt regarding malloc allocting memory. How does malloc
stores information about the size ofthe pointer as free uses only
pointer variable as argument and not the size. can u explain which
part ofaddress space it is stored..?
72.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
14 de 41 13/01/2014 04:16 p.m.
-
Thanks in advance
Keith Johnson on April 30th, 2009 9:14 am
Awesome post! Indeed, memory management cannot be
overlooked.
73.
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 andkernel.
@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!
74.
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 postabout Intel CPU caches shows
a blue index for the virtually [...]
75.
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-leveldebugging at the system level.
Near the top of this post, you mention ring 2 or lower as if we
shouldall just know what that even means, and Im sorry to say that
I do not. Could you point me to a docthatll explain that, or could
you expand on what this notion of rings relates to?
Thanks all of your posts are top notch.
76.
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
77.
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.
78.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
15 de 41 13/01/2014 04:16 p.m.
-
EW on July 2nd, 2009 11:38 am
Very good article. Thanks!
79.
ks on July 13th, 2009 9:06 am
Thanks for the great article thats so simple and crisp.
80.
wei on July 22nd, 2009 11:17 pm
Great post! Solve tons of doubts of mine.Though I still have a
few questions hope you can clarify for me.If I understand them
right:1)The kernel stuff of kernel space (1GB) is in the physical
memory (1GB) all the time, unless a userprocess is trying to access
the physical memory mapped to kernel space. If that is the case,
swappingwill happen. Right?
2)So if I only have enough physical memory for kernel mapping,
all my user processes will need to usethe memory mapped to kernel.
So I will have a lot swapping going on. Right?
3)Why 1GB? Is it based on the size of resident processes and
other necessary structures? Or is ithardware related?
Thanks in advance!
81.
Abhijith on July 25th, 2009 11:21 am
Superbly explained. Love the diagrams. Great work!
82.
Dean on August 4th, 2009 8:03 pm
AWESOME articles, extremely helpful! MANY THANKS for all your
postings! Keep them comingIhave you book-marked! As a professional
technician, I admire your efforts!
83.
KS on August 23rd, 2009 3:55 pm
This is excellent, probably the best technical documentation Ive
ever found on a blog. Thank you!
84.
yodacallmesome on September 14th, 2009 2:56 am
Nice article. It should be noted that there is a special case:
When clone(2) is used instead of fork(2) tocreate a process, the
address mappings are replicated (stack excepted).
85.
Godmar Back on September 23rd, 2009 2:22 pm
Its not clear which kernel/libc version above information
applies to.
For instance, on CentOS 5.3 running a 2.6.18 kernel with Redhats
patches 2.6.18-128.7.1.el5PAE andGNU libc 2.5, some shared
libraries are located beneath the code segment which contradicts
thefigure shown above.
> tac /proc/21779/maps
86.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
16 de 41 13/01/2014 04:16 p.m.
-
bfeba000-bff0f000 rw-p bffaa000 00:00 0 [stack]b7f98000-b7f9f000
rs 00000000 fd:00 36079468
/usr/lib/gconv/gconv-modules.cacheb7f93000-b7f95000 rw-p b7f93000
00:00 0b7d93000-b7f93000 rp 00000000 fd:00 36001563
/usr/lib/locale/locale-archive08ae9000-08b4c000 rw-p 08ae9000 00:00
0 [heap]0809c000-080f9000 rw-p 0809c000 00:00 008098000-0809c000
rw-p 00050000 fd:00 90800216 /bin/tcsh08047000-08098000 r-xp
00000000 fd:00 90800216 /bin/tcsh02b4d000-02b4e000 rwxp 00002000
fd:00 95783275 /lib/libtermcap.so.2.0.802b4a000-02b4d000 r-xp
00000000 fd:00 95783275 /lib/libtermcap.so.2.0.8028ac000-028d3000
rwxp 028ac000 00:00 0028ab000-028ac000 rwxp 00009000 fd:00 95783323
/lib/libcrypt-2.5.so028aa000-028ab000 r-xp 00008000 fd:00 95783323
/lib/libcrypt-2.5.so028a1000-028aa000 r-xp 00000000 fd:00 95783323
/lib/libcrypt-2.5.so0090a000-0090b000 rwxp 00009000 fd:00 95780903
/lib/libnss_files-2.5.so00909000-0090a000 r-xp 00008000 fd:00
95780903 /lib/libnss_files-2.5.so00900000-00909000 r-xp 00000000
fd:00 95780903 /lib/libnss_files-2.5.so008da000-008dc000 rwxp
008da000 00:00 0008d9000-008da000 rwxp 0000f000 fd:00 95783322
/lib/libresolv-2.5.so008d8000-008d9000 r-xp 0000e000 fd:00 95783322
/lib/libresolv-2.5.so008c9000-008d8000 r-xp 00000000 fd:00 95783322
/lib/libresolv-2.5.so006d4000-006d7000 rwxp 006d4000 00:00
0006d3000-006d4000 rwxp 00140000 fd:00 95781738
/lib/libc-2.5.so006d1000-006d3000 r-xp 0013e000 fd:00 95781738
/lib/libc-2.5.so00593000-006d1000 r-xp 00000000 fd:00 95781738
/lib/libc-2.5.so00480000-00481000 rwxp 0001a000 fd:00 95780954
/lib/ld-2.5.so0047f000-00480000 r-xp 00019000 fd:00 95780954
/lib/ld-2.5.so00465000-0047f000 r-xp 00000000 fd:00 95780954
/lib/ld-2.5.so00451000-00452000 r-xp 00451000 00:00 0
[vdso]00115000-00116000 rwxp 00004000 fd:00 95780901
/lib/libnss_dns-2.5.so00114000-00115000 r-xp 00003000 fd:00
95780901 /lib/libnss_dns-2.5.so00110000-00114000 r-xp 00000000
fd:00 95780901 /lib/libnss_dns-2.5.so
Travis on September 25th, 2009 7:57 am
Thanks for the info I was looking for a graph like that.
Studying kernel and memory functions inclass at the moment, so its
helpful to have a visual.
87.
Vikram Gupta on October 9th, 2009 5:38 am
Good work
very well explained.
88.
Mukesh Chauhan on October 14th, 2009 4:49 am
The article explains the memory layout for 32-bit architecture.
How it will be different in 64-bitarchitecture? Please give brief
explaination or provide any link for the same.
89.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
17 de 41 13/01/2014 04:16 p.m.
-
Thanks,-Mukesh Chauhan
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-executeright ? So, only read perm
?
90.
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!
91.
Amit Pande on December 22nd, 2009 1:47 am
Great articleno other links I googled explains fundamentals
better than this ! Not sure how comeGoogle did not rank it
higher
92.
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 [...]
93.
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
94.
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 myfirefox 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-stub0804f000-08050000 rw-p
00006000 08:01 1893676
/usr/lib/xulrunner-1.9/xulrunner-stub0810c000-0c599000 rw-p
00000000 00:00 0 [heap]ad6ff000-ad700000 p 00000000 00:00
0ad700000-adf00000 rw-p 00000000 00:00 0
95.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
18 de 41 13/01/2014 04:16 p.m.
-
adf00000-ae000000 rw-p 00000000 00:00 0ae84a000-ae84b000 p
00000000 00:00 0ae84b000-af04b000 rw-p 00000000 00:00
0af2dc000-af6f0000 rw-p 00000000 00:00 0af84c000-af863000 r-xp
00000000 08:01 2949172 /lib/libselinux.so.1af863000-af865000 rw-p
00016000 08:01 2949172 /lib/libselinux.so.1af865000-af874000 r-xp
00000000 08:01 2949251 /lib/libbz2.so.1.0.4af874000-af875000 rw-p
0000f000 08:01 2949251 /lib/libbz2.so.1.0.4af875000-af8d6000 r-xp
00000000 08:01 1749980
/usr/lib/libgio-2.0.so.0.0.0af8d6000-af8d8000 rw-p 00060000 08:01
1749980 /usr/lib/libgio-2.0.so.0.0.0af8d8000-af909000 r-xp 00000000
08:01 5038179 /usr/lib/libcroco-0.6.so.3.0.1af909000-af90c000 rw-p
00030000 08:01 5038179
/usr/lib/libcroco-0.6.so.3.0.1af90c000-af93d000 r-xp 00000000 08:01
5038181 /usr/lib/libgsf-1.so.114.0.8af93d000-af940000 rw-p 00030000
08:01 5038181 /usr/lib/libgsf-1.so.114.0.8af940000-af941000 rw-p
00000000 00:00 0af941000-af971000 r-xp 00000000 08:01 1751442
/usr/lib/librsvg-2.so.2.22.2af971000-af972000 rw-p 00030000 08:01
1751442 /usr/lib/librsvg-2.so.2.22.2af985000-af994000 rp 00000000
08:01 1952770
/usr/share/icons/Gorilla/icon-theme.cacheaf994000-afa16000 rw-p
00000000 00:00 0afa16000-afa61000 rp 00000000 08:01 1787608
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttfafa61000-afa62000
p 00000000 00:00 0afa62000-b0262000 rw-p 00000000 00:00
0b0262000-b0263000 p 00000000 00:00 0b0263000-b0a63000 rw-p
00000000 00:00 0b0a63000-b0aaa000 r-xp 00000000 08:01 1843812
/usr/lib/nss/libnssckbi.sob0aaa000-b0ab6000 rw-p 00046000 08:01
1843812 /usr/lib/nss/libnssckbi.sob0ab6000-b0af6000 r-xp 00000000
08:01 1843809 /usr/lib/nss/libfreebl3.sob0af6000-b0af7000 rw-p
0003f000 08:01 1843809 /usr/lib/nss/libfreebl3.sob0af7000-b0afb000
rw-p 00000000 00:00 0b0aff000-b0b00000 p 00000000 00:00
0b0b00000-b1300000 rw-p 00000000 00:00 0b1300000-b13fe000 rw-p
00000000 00:00 0b13fe000-b1400000 p 00000000 00:00
0b1400000-b149c000 rw-p 00000000 00:00 0b149c000-b1500000 p
00000000 00:00 0b1500000-b1700000 rw-p 00000000 00:00
0b1700000-b1900000 rw-p 00000000 00:00 0b1900000-b1a00000 rw-p
00000000 00:00 0b1afd000-b1afe000 p 00000000 00:00
0b1afe000-b22fe000 rw-p 00000000 00:00 0b2300000-b24a6000 rw-p
00000000 00:00 0b24a6000-b2500000 p 00000000 00:00
0b2500000-b26ff000 rw-p 00000000 00:00 0b26ff000-b2700000 p
00000000 00:00 0b2700000-b27ff000 rw-p 00000000 00:00
0b27ff000-b2800000 p 00000000 00:00 0b2800000-b2900000 rw-p
00000000 00:00 0b2900000-b2a00000 rw-p 00000000 00:00 0
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
19 de 41 13/01/2014 04:16 p.m.
-
b2a46000-b2a55000 rp 00000000 08:01 1952770
/usr/share/icons/Gorilla/icon-theme.cacheb2a55000-b2a59000 r-xp
00000000 08:01 2949170 /lib/libattr.so.1.1.0b2a59000-b2a5a000 rw-p
00003000 08:01 2949170 /lib/libattr.so.1.1.0b2a5a000-b2a60000 r-xp
00000000 08:01 2949167 /lib/libacl.so.1.1.0b2a60000-b2a61000 rw-p
00005000 08:01 2949167 /lib/libacl.so.1.1.0b2a66000-b2a6c000 r-xp
00000000 08:01 1771346
/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-xpm.sob2a6c000-b2a6d000
rw-p 00005000 08:01 1771346
/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-xpm.sob2a6d000-b2a74000
rp 00000000 08:01 2294627
/home/divkis01/.icons/gartoon/icon-theme.cacheb2a74000-b2a80000
r-xp 00000000 08:01 1802453
/usr/lib/gnome-vfs-2.0/modules/libfile.sob2a80000-b2a81000 rw-p
0000b000 08:01 1802453
/usr/lib/gnome-vfs-2.0/modules/libfile.sob2a81000-b2a94000 r-xp
00000000 08:01 1941882
/usr/lib/totem/gstreamer/libtotem-narrowspace-plugin.sob2a94000-b2a95000
rw-p 00013000 08:01 1941882
/usr/lib/totem/gstreamer/libtotem-narrowspace-plugin.sob2a95000-b2aa4000
r-xp 00000000 08:01 1941881
/usr/lib/totem/gstreamer/libtotem-mully-plugin.sob2aa4000-b2aa5000
rw-p 0000f000 08:01 1941881
/usr/lib/totem/gstreamer/libtotem-mully-plugin.sob2aa5000-b2aba000
r-xp 00000000 08:01 1941880
/usr/lib/totem/gstreamer/libtotem-gmp-plugin.sob2aba000-b2abb000
rw-p 00015000 08:01 1941880
/usr/lib/totem/gstreamer/libtotem-gmp-plugin.sob2abb000-b2aff000 rp
00000000 08:01 1787611
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif-Italic.ttfb2c10000-b2c91000
rw-p 00000000 00:00 0b2d65000-b2e08000 r-xp 00000000 08:01 5038227
/usr/lib/libgstreamer-0.10.so.0.16.0b2e08000-b2e0c000 rw-p 000a3000
08:01 5038227 /usr/lib/libgstreamer-0.10.so.0.16.0b2e0c000-b2e16000
r-xp 00000000 08:01 5038237
/usr/lib/libgstpbutils-0.10.so.0.13.0b2e16000-b2e17000 rw-p
0000a000 08:01 5038237
/usr/lib/libgstpbutils-0.10.so.0.13.0b2e17000-b2edc000 r-xp
00000000 08:01 1752166 /usr/lib/libasound.so.2.0.0b2edc000-b2ee0000
rw-p 000c5000 08:01 1752166
/usr/lib/libasound.so.2.0.0b2ee0000-b2f15000 r-xp 00000000 08:01
5038394 /usr/lib/libsoup-2.4.so.1.1.0b2f15000-b2f17000 rw-p
00034000 08:01 5038394
/usr/lib/libsoup-2.4.so.1.1.0b2f17000-b2f6c000 r-xp 00000000 08:01
5038264 /usr/lib/liboil-0.3.so.0.3.0b2f6c000-b2f83000 rw-p 00055000
08:01 5038264 /usr/lib/liboil-0.3.so.0.3.0b2f83000-b2f85000 rw-p
00000000 00:00 0b2f85000-b3056000 r-xp 00000000 08:01 5038723
/usr/lib/libswfdec-0.6.so.90.0.0b3056000-b305d000 rw-p 000d1000
08:01 5038723 /usr/lib/libswfdec-0.6.so.90.0.0b305d000-b3067000
r-xp 00000000 08:01 5038724
/usr/lib/libswfdec-gtk-0.6.so.90.0.0b3067000-b3068000 rw-p 0000a000
08:01 5038724 /usr/lib/libswfdec-gtk-0.6.so.90.0.0b307b000-b307d000
r-xp 00000000 08:01 1804250
/usr/lib/pango/1.6.0/modules/pango-hangul-fc.sob307d000-b307e000
rw-p 00001000 08:01 1804250
/usr/lib/pango/1.6.0/modules/pango-hangul-fc.sob307e000-b310f000
rw-p 00000000 00:00 0b310f000-b3111000 r-xp 00000000 08:01 2949485
/lib/libnss_mdns4.so.2b3111000-b3112000 rw-p 00001000 08:01 2949485
/lib/libnss_mdns4.so.2b3119000-b3124000 r-xp 00000000 08:01 1976017
/usr/lib/swfdec-mozilla/libswfdecmozilla.sob3124000-b3125000 rw-p
0000b000 08:01 1976017
/usr/lib/swfdec-mozilla/libswfdecmozilla.sob315b000-b31d8000 rp
00000000 08:01 1787618
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Oblique.ttfb31d8000-b326d000
rp 00000000 08:01 1787607
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
20 de 41 13/01/2014 04:16 p.m.
-
b326d000-b32b4000 rp 00000000 08:01 1787606
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Bold.ttfb32b4000-b3300000
rp 00000000 08:01 1787604
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttfb3300000-b33fd000
rw-p 00000000 00:00 0b33fd000-b3400000 p 00000000 00:00
0b3400000-b3500000 rw-p 00000000 00:00 0b3500000-b3600000 rw-p
00000000 00:00 0b3603000-b3618000 r-xp 00000000 08:01 1941878
/usr/lib/totem/gstreamer/libtotem-complex-plugin.sob3618000-b3619000
rw-p 00015000 08:01 1941878
/usr/lib/totem/gstreamer/libtotem-complex-plugin.sob3619000-b365b000
rp 00000000 08:01 1787617
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif-BoldItalic.ttfb365b000-b36bb000
rw-s 00000000 00:04 557069 /SYSV00000000 (deleted)b36bb000-b3700000
rp 00000000 08:01 1787609
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif-Bold.ttfb3700000-b3900000
rw-p 00000000 00:00 0b3900000-b39f8000 rw-p 00000000 00:00
0b39f8000-b3a00000 p 00000000 00:00 0b3a03000-b3a0b000 r-xp
00000000 08:01 5038149 /usr/lib/libfam.so.0.0.0b3a0b000-b3a0c000
rw-p 00007000 08:01 5038149
/usr/lib/libfam.so.0.0.0b3a0c000-b3a1e000 rs 00000000 08:01 1810837
/usr/share/mime/mime.cacheb3a1e000-b3a1f000 p 00000000 00:00
0b3a1f000-b421f000 rw-p 00000000 00:00 0b421f000-b4223000 r-xp
00000000 08:01 2958660
/lib/i686/cmov/libnss_dns-2.7.sob4223000-b4225000 rw-p 00003000
08:01 2958660 /lib/i686/cmov/libnss_dns-2.7.sob4225000-b4227000
r-xp 00000000 08:01 2949486
/lib/libnss_mdns4_minimal.so.2b4227000-b4228000 rw-p 00001000 08:01
2949486 /lib/libnss_mdns4_minimal.so.2b4229000-b422b000 r-xp
00000000 08:01 5038541
/usr/lib/libtotem-plparser-mini.so.10.1.1b422b000-b422c000 rw-p
00001000 08:01 5038541
/usr/lib/libtotem-plparser-mini.so.10.1.1b422c000-b423a000 r-xp
00000000 08:01 1941877
/usr/lib/totem/gstreamer/libtotem-basic-plugin.sob423a000-b423b000
rw-p 0000d000 08:01 1941877
/usr/lib/totem/gstreamer/libtotem-basic-plugin.sob423b000-b4242000
r-xp 00000000 08:01 1893797
/usr/lib/xulrunner-1.9/components/libmozgnome.sob4242000-b4243000
rw-p 00007000 08:01 1893797
/usr/lib/xulrunner-1.9/components/libmozgnome.sob424e000-b4284000
rp 00000000 08:01 1787613
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Oblique.ttfb4284000-b4388000
rw-p 00000000 00:00 0b4388000-b4411000 rp 00000000 08:01 1787605
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttfb4411000-b4412000
r-xp 00000000 08:01 1771438
/usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.sob4412000-b4413000 rw-p
00000000 08:01 1771438
/usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.sob4413000-b441a000 rp
00000000 08:01 2294627
/home/divkis01/.icons/gartoon/icon-theme.cacheb441a000-b4436000
r-xp 00000000 08:01 1843811
/usr/lib/nss/libnssdbm3.sob4436000-b4437000 rw-p 0001c000 08:01
1843811 /usr/lib/nss/libnssdbm3.sob4437000-b4463000 r-xp 00000000
08:01 1843810 /usr/lib/nss/libsoftokn3.so
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
21 de 41 13/01/2014 04:16 p.m.
-
b4463000-b4464000 rw-p 0002c000 08:01 1843810
/usr/lib/nss/libsoftokn3.sob4464000-b4488000 r-xp 00000000 08:01
2213359
/usr/lib/iceweasel/components/libbrowsercomps.sob4488000-b448a000
rw-p 00024000 08:01 2213359
/usr/lib/iceweasel/components/libbrowsercomps.sob448a000-b448c000
r-xp 00000000 08:01 5038433
/usr/lib/libXss.so.1.0.0b448c000-b448d000 rw-p 00001000 08:01
5038433 /usr/lib/libXss.so.1.0.0b448e000-b4497000 r-xp 00000000
08:01 1893644
/usr/lib/xulrunner-1.9/components/libimgicon.sob4497000-b4498000
rw-p 00009000 08:01 1893644
/usr/lib/xulrunner-1.9/components/libimgicon.sob4498000-b449f000
r-xp 00000000 08:01 1893799
/usr/lib/xulrunner-1.9/components/libnkgnomevfs.sob449f000-b44a0000
rw-p 00007000 08:01 1893799
/usr/lib/xulrunner-1.9/components/libnkgnomevfs.sob44a0000-b44a6000
rs 00000000 08:01 5931227
/var/cache/fontconfig/945677eb7aeaf62f1d50efc3fb3ec7d8-x86.cache-2b44a6000-b44a9000
rs 00000000 08:01 5931203
/var/cache/fontconfig/6eb3985aa4124903f6ff08ba781cd364-x86.cache-2b44a9000-b44b0000
rs 00000000 08:01 5931201
/var/cache/fontconfig/6d41288fd70b0be22e8c3a91e032eec0-x86.cache-2b44b0000-b44b1000
rs 00000000 08:01 5931199
/var/cache/fontconfig/4794a0821666d79190d59a36cb4f44b5-x86.cache-2b44b1000-b44b3000
rs 00000000 08:01 5931196
/var/cache/fontconfig/2c5ba8142dffc8bf0377700342b8ca1a-x86.cache-2b44b3000-b44c0000
rs 00000000 08:01 5931172
/var/cache/fontconfig/e13b20fdb08344e0e664864cc2ede53d-x86.cache-2b44c0000-b44ce000
rs 00000000 08:01 5931230
/var/cache/fontconfig/865f88548240fee46819705c6468c165-x86.cache-2b44ce000-b44cf000
p 00000000 00:00 0b44cf000-b4ccf000 rw-p 00000000 00:00
0b4ccf000-b4d2f000 rw-s 00000000 00:04 524300 /SYSV00000000
(deleted)b4d2f000-b4d33000 r-xp 00000000 08:01 1771345
/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.sob4d33000-b4d34000
rw-p 00003000 08:01 1771345
/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.sob4d34000-b4d3c000
r-xp 00000000 08:01 1771772
/usr/lib/gtk-2.0/2.10.0/engines/libpixmap.sob4d3c000-b4d3d000 rw-p
00007000 08:01 1771772
/usr/lib/gtk-2.0/2.10.0/engines/libpixmap.sob4d3d000-b4d3e000 p
00000000 00:00 0b4d3e000-b553e000 rw-p 00000000 00:00
0b553e000-b5547000 r-xp 00000000 08:01 2213355
/usr/lib/iceweasel/components/libbrowserdirprovider.sob5547000-b5548000
rw-p 00008000 08:01 2213355
/usr/lib/iceweasel/components/libbrowserdirprovider.sob5548000-b55ae000
r-xp 00000000 08:01 1748133
/usr/lib/libgcrypt.so.11.4.4b55ae000-b55b0000 rw-p 00066000 08:01
1748133 /usr/lib/libgcrypt.so.11.4.4b55b0000-b55b3000 r-xp 00000000
08:01 1748135 /usr/lib/libgpg-error.so.0.3.0b55b3000-b55b4000 rw-p
00002000 08:01 1748135
/usr/lib/libgpg-error.so.0.3.0b55b4000-b55c3000 r-xp 00000000 08:01
1748163 /usr/lib/libtasn1.so.3.0.15b55c3000-b55c4000 rw-p 0000e000
08:01 1748163 /usr/lib/libtasn1.so.3.0.15b55c4000-b55c8000 r-xp
00000000 08:01 5038132 /usr/lib/libORBitCosNaming-2.so.0.1.0
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
22 de 41 13/01/2014 04:16 p.m.
-
b55c8000-b55c9000 rw-p 00003000 08:01 5038132
/usr/lib/libORBitCosNaming-2.so.0.1.0b55c9000-b55cb000 r-xp
00000000 08:01 2958671
/lib/i686/cmov/libutil-2.7.sob55cb000-b55cd000 rw-p 00001000 08:01
2958671 /lib/i686/cmov/libutil-2.7.sob55cd000-b55dd000 r-xp
00000000 08:01 2958667
/lib/i686/cmov/libresolv-2.7.sob55dd000-b55df000 rw-p 0000f000
08:01 2958667 /lib/i686/cmov/libresolv-2.7.sob55df000-b55e1000 rw-p
00000000 00:00 0b55e1000-b55f0000 r-xp 00000000 08:01 1749775
/usr/lib/libavahi-client.so.3.2.4b55f0000-b55f1000 rw-p 0000e000
08:01 1749775 /usr/lib/libavahi-client.so.3.2.4b55f1000-b55fc000
r-xp 00000000 08:01 1749773
/usr/lib/libavahi-common.so.3.5.0b55fc000-b55fd000 rw-p 0000a000
08:01 1749773 /usr/lib/libavahi-common.so.3.5.0b55fd000-b5694000
r-xp 00000000 08:01 1749770
/usr/lib/libgnutls.so.26.4.6b5694000-b569a000 rw-p 00097000 08:01
1749770 /usr/lib/libgnutls.so.26.4.6b569a000-b56d0000 r-xp 00000000
08:01 1749771 /usr/lib/libdbus-1.so.3.4.0b56d0000-b56d2000 rw-p
00035000 08:01 1749771 /usr/lib/libdbus-1.so.3.4.0b56d2000-b56ed000
r-xp 00000000 08:01 1749988
/usr/lib/libdbus-glib-1.so.2.1.0b56ed000-b56ee000 rw-p 0001b000
08:01 1749988 /usr/lib/libdbus-glib-1.so.2.1.0b56ee000-b570e000
r-xp 00000000 08:01 5038143
/usr/lib/libaudiofile.so.0.0.2b570e000-b5711000 rw-p 0001f000 08:01
5038143 /usr/lib/libaudiofile.so.0.0.2b5711000-b5719000 r-xp
00000000 08:01 5038145 /usr/lib/libesd.so.0.2.36b5719000-b571a000
rw-p 00007000 08:01 5038145
/usr/lib/libesd.so.0.2.36b571a000-b5720000 r-xp 00000000 08:01
1751390 /usr/lib/libgailutil.so.18.0.1b5720000-b5721000 rw-p
00006000 08:01 1751390
/usr/lib/libgailutil.so.18.0.1b5721000-b5729000 r-xp 00000000 08:01
2949412 /lib/libpopt.so.0.0.0b5729000-b572a000 rw-p 00007000 08:01
2949412 /lib/libpopt.so.0.0.0b572a000-b585d000 r-xp 00000000 08:01
1748162 /usr/lib/libxml2.so.2.6.32b585d000-b5862000 rw-p 00132000
08:01 1748162 /usr/lib/libxml2.so.2.6.32b5862000-b5863000 rw-p
00000000 00:00 0b5863000-b58ac000 r-xp 00000000 08:01 5038133
/usr/lib/libORBit-2.so.0.1.0b58ac000-b58b5000 rw-p 00049000 08:01
5038133 /usr/lib/libORBit-2.so.0.1.0b58b5000-b58b6000 rw-p 00000000
00:00 0b58b6000-b58c8000 r-xp 00000000 08:01 5038137
/usr/lib/libbonobo-activation.so.4.0.0b58c8000-b58ca000 rw-p
00012000 08:01 5038137
/usr/lib/libbonobo-activation.so.4.0.0b58ca000-b591c000 r-xp
00000000 08:01 5038138
/usr/lib/libbonobo-2.so.0.0.0b591c000-b5926000 rw-p 00051000 08:01
5038138 /usr/lib/libbonobo-2.so.0.0.0b5926000-b5935000 r-xp
00000000 08:01 5038163
/usr/lib/libgnome-keyring.so.0.1.1b5935000-b5936000 rw-p 0000f000
08:01 5038163 /usr/lib/libgnome-keyring.so.0.1.1b5936000-b5965000
r-xp 00000000 08:01 1751370
/usr/lib/libgconf-2.so.4.1.5b5965000-b5968000 rw-p 0002e000 08:01
1751370 /usr/lib/libgconf-2.so.4.1.5b5968000-b59c0000 r-xp 00000000
08:01 5038155 /usr/lib/libgnomevfs-2.so.0.2200.0b59c0000-b59c3000
rw-p 00057000 08:01 5038155
/usr/lib/libgnomevfs-2.so.0.2200.0b59c3000-b59d8000 r-xp 00000000
08:01 5038127 /usr/lib/libart_lgpl_2.so.2.3.20b59d8000-b59d9000
rw-p 00014000 08:01 5038127
/usr/lib/libart_lgpl_2.so.2.3.20b59d9000-b59ed000 r-xp 00000000
08:01 5038157 /usr/lib/libgnome-2.so.0.1999.2b59ed000-b59ee000 rw-p
00013000 08:01 5038157
/usr/lib/libgnome-2.so.0.1999.2b59ee000-b5a1d000 r-xp 00000000
08:01 1751440
/usr/lib/libgnomecanvas-2.so.0.2001.0b5a1d000-b5a1e000 rw-p
0002f000 08:01 1751440
/usr/lib/libgnomecanvas-2.so.0.2001.0b5a1e000-b5a79000 r-xp
00000000 08:01 5038335
/usr/lib/libbonoboui-2.so.0.0.0b5a79000-b5a7c000 rw-p 0005a000
08:01 5038335 /usr/lib/libbonoboui-2.so.0.0.0
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
23 de 41 13/01/2014 04:16 p.m.
-
b5a7c000-b5b05000 r-xp 00000000 08:01 5038337
/usr/lib/libgnomeui-2.so.0.2000.1b5b05000-b5b09000 rw-p 00088000
08:01 5038337 /usr/lib/libgnomeui-2.so.0.2000.1b5b09000-b5b13000
r-xp 00000000 08:01 2958661
/lib/i686/cmov/libnss_files-2.7.sob5b13000-b5b15000 rw-p 00009000
08:01 2958661 /lib/i686/cmov/libnss_files-2.7.sob5b15000-b5b1e000
r-xp 00000000 08:01 2958663
/lib/i686/cmov/libnss_nis-2.7.sob5b1e000-b5b20000 rw-p 00008000
08:01 2958663 /lib/i686/cmov/libnss_nis-2.7.sob5b20000-b5b35000
r-xp 00000000 08:01 2958658
/lib/i686/cmov/libnsl-2.7.sob5b35000-b5b37000 rw-p 00014000 08:01
2958658 /lib/i686/cmov/libnsl-2.7.sob5b37000-b5b39000 rw-p 00000000
00:00 0b5b3a000-b5b40000 r-xp 00000000 08:01 1893798
/usr/lib/xulrunner-1.9/components/libdbusservice.sob5b40000-b5b41000
rw-p 00005000 08:01 1893798
/usr/lib/xulrunner-1.9/components/libdbusservice.sob5b41000-b5b43000
r-xp 00000000 08:01 1746335
/usr/lib/gconv/UTF-16.sob5b43000-b5b45000 rw-p 00001000 08:01
1746335 /usr/lib/gconv/UTF-16.sob5b45000-b5b4c000 rs 00000000 08:01
1747425 /usr/lib/gconv/gconv-modules.cacheb5b4c000-b5c86000 rp
00000000 08:01 1762716
/usr/lib/locale/locale-archiveb5c86000-b5c8a000 r-xp 00000000 08:01
1750470 /usr/lib/libXdmcp.so.6.0.0b5c8a000-b5c8b000 rw-p 00003000
08:01 1750470 /usr/lib/libXdmcp.so.6.0.0b5c8b000-b5c8d000 r-xp
00000000 08:01 1750468 /usr/lib/libXau.so.6.0.0b5c8d000-b5c8e000
rw-p 00001000 08:01 1750468
/usr/lib/libXau.so.6.0.0b5c8e000-b5c95000 r-xp 00000000 08:01
2958668 /lib/i686/cmov/librt-2.7.sob5c95000-b5c97000 rw-p 00006000
08:01 2958668 /lib/i686/cmov/librt-2.7.sob5c97000-b5cab000 r-xp
00000000 08:01 1750480 /usr/lib/libICE.so.6.3.0b5cab000-b5cac000
rw-p 00014000 08:01 1750480
/usr/lib/libICE.so.6.3.0b5cac000-b5cae000 rw-p 00000000 00:00
0b5cae000-b5cb5000 r-xp 00000000 08:01 1750482
/usr/lib/libSM.so.6.0.0b5cb5000-b5cb6000 rw-p 00006000 08:01
1750482 /usr/lib/libSM.so.6.0.0b5cb6000-b5cbe000 r-xp 00000000
08:01 1750606 /usr/lib/libXcursor.so.1.0.2b5cbe000-b5cbf000 rw-p
00007000 08:01 1750606
/usr/lib/libXcursor.so.1.0.2b5cbf000-b5cc4000 r-xp 00000000 08:01
1750760 /usr/lib/libXrandr.so.2.1.0b5cc4000-b5cc5000 rw-p 00005000
08:01 1750760 /usr/lib/libXrandr.so.2.1.0b5cc5000-b5ccc000 r-xp
00000000 08:01 1750692 /usr/lib/libXi.so.6.0.0b5ccc000-b5ccd000
rw-p 00007000 08:01 1750692
/usr/lib/libXi.so.6.0.0b5ccd000-b5ccf000 r-xp 00000000 08:01
1750694 /usr/lib/libXinerama.so.1.0.0b5ccf000-b5cd0000 rw-p
00001000 08:01 1750694
/usr/lib/libXinerama.so.1.0.0b5cd0000-b5cdd000 r-xp 00000000 08:01
1750592 /usr/lib/libXext.so.6.4.0b5cdd000-b5cde000 rw-p 0000c000
08:01 1750592 /usr/lib/libXext.so.6.4.0b5cde000-b5ce2000 r-xp
00000000 08:01 1750478 /usr/lib/libXfixes.so.3.1.0b5ce2000-b5ce3000
rw-p 00003000 08:01 1750478
/usr/lib/libXfixes.so.3.1.0b5ce3000-b5ce5000 r-xp 00000000 08:01
1750686 /usr/lib/libXdamage.so.1.1.0b5ce5000-b5ce6000 rw-p 00001000
08:01 1750686 /usr/lib/libXdamage.so.1.1.0b5ce6000-b5ce8000 r-xp
00000000 08:01 5038113
/usr/lib/libXcomposite.so.1.0.0b5ce8000-b5ce9000 rw-p 00001000
08:01 5038113 /usr/lib/libXcomposite.so.1.0.0b5ce9000-b5cea000 r-xp
00000000 08:01 1750474
/usr/lib/libxcb-xlib.so.0.0.0b5cea000-b5ceb000 rw-p 00000000 08:01
1750474 /usr/lib/libxcb-xlib.so.0.0.0b5ceb000-b5d13000 r-xp
00000000 08:01 1749972 /usr/lib/libpcre.so.3.12.1b5d13000-b5d14000
rw-p 00027000 08:01 1749972 /usr/lib/libpcre.so.3.12.1
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
24 de 41 13/01/2014 04:16 p.m.
-
b5d14000-b5d38000 r-xp 00000000 08:01 1747333
/usr/lib/libexpat.so.1.5.2b5d38000-b5d3a000 rw-p 00023000 08:01
1747333 /usr/lib/libexpat.so.1.5.2b5d3a000-b5d62000 r-xp 00000000
08:01 5038087 /usr/lib/libpixman-1.so.0.10.0b5d62000-b5d63000 rw-p
00027000 08:01 5038087
/usr/lib/libpixman-1.so.0.10.0b5d63000-b5d7a000 r-xp 00000000 08:01
1750472 /usr/lib/libxcb.so.1.0.0b5d7a000-b5d7b000 rw-p 00017000
08:01 1750472 /usr/lib/libxcb.so.1.0.0b5d7b000-b5d81000 r-xp
00000000 08:01 5038089
/usr/lib/libxcb-render.so.0.0.0b5d81000-b5d82000 rw-p 00005000
08:01 5038089 /usr/lib/libxcb-render.so.0.0.0b5d82000-b5d85000 r-xp
00000000 08:01 5038091
/usr/lib/libxcb-render-util.so.0.0.0b5d85000-b5d86000 rw-p 00002000
08:01 5038091 /usr/lib/libxcb-render-util.so.0.0.0b5d86000-b5d99000
r-xp 00000000 08:01 1750908
/usr/lib/libdirect-1.0.so.0.1.0b5d99000-b5d9a000 rw-p 00012000
08:01 1750908 /usr/lib/libdirect-1.0.so.0.1.0b5d9a000-b5da1000 r-xp
00000000 08:01 5038081
/usr/lib/libfusion-1.0.so.0.1.0b5da1000-b5da2000 rw-p 00006000
08:01 5038081 /usr/lib/libfusion-1.0.so.0.1.0b5da2000-b5e07000 r-xp
00000000 08:01 1750909
/usr/lib/libdirectfb-1.0.so.0.1.0b5e07000-b5e09000 rw-p 00065000
08:01 1750909 /usr/lib/libdirectfb-1.0.so.0.1.0b5e09000-b5e0c000
r-xp 00000000 08:01 1749981
/usr/lib/libgmodule-2.0.so.0.1600.6b5e0c000-b5e0d000 rw-p 00002000
08:01 1749981 /usr/lib/libgmodule-2.0.so.0.1600.6b5e0d000-b5e14000
r-xp 00000000 08:01 5038314
/usr/lib/libstartup-notification-1.so.0.0.0b5e14000-b5e15000 rw-p
00007000 08:01 5038314
/usr/lib/libstartup-notification-1.so.0.0.0b5e15000-b5e19000 r-xp
00000000 08:01 1749978
/usr/lib/libgthread-2.0.so.0.1600.6b5e19000-b5e1a000 rw-p 00003000
08:01 1749978 /usr/lib/libgthread-2.0.so.0.1600.6b5e1a000-b5e66000
r-xp 00000000 08:01 1750484
/usr/lib/libXt.so.6.0.0b5e66000-b5e69000 rw-p 0004c000 08:01
1750484 /usr/lib/libXt.so.6.0.0b5e69000-b5e6a000 rw-p 00000000
00:00 0b5e6a000-b5e81000 r-xp 00000000 08:01 1751381
/usr/lib/libgdk_pixbuf-2.0.so.0.1200.12b5e81000-b5e82000 rw-p
00017000 08:01 1751381
/usr/lib/libgdk_pixbuf-2.0.so.0.1200.12b5e82000-b5f05000 r-xp
00000000 08:01 1751382
/usr/lib/libgdk-x11-2.0.so.0.1200.12b5f05000-b5f08000 rw-p 00083000
08:01 1751382 /usr/lib/libgdk-x11-2.0.so.0.1200.12b5f08000-b5f21000
r-xp 00000000 08:01 5038097
/usr/lib/libatk-1.0.so.0.2209.1b5f21000-b5f23000 rw-p 00018000
08:01 5038097 /usr/lib/libatk-1.0.so.0.2209.1b5f23000-b62a7000 r-xp
00000000 08:01 1751380
/usr/lib/libgtk-x11-2.0.so.0.1200.12b62a7000-b62ad000 rw-p 00383000
08:01 1751380 /usr/lib/libgtk-x11-2.0.so.0.1200.12b62ad000-b62ae000
rw-p 00000000 00:00 0b62ae000-b62c3000 r-xp 00000000 08:01 2958666
/lib/i686/cmov/libpthread-2.7.sob62c3000-b62c5000 rw-p 00014000
08:01 2958666 /lib/i686/cmov/libpthread-2.7.sob62c5000-b62c7000
rw-p 00000000 00:00 0b62c7000-b62f8000 r-xp 00000000 08:01 5038202
/usr/lib/libnspr4.so.0db62f8000-b62f9000 rw-p 00031000 08:01
5038202 /usr/lib/libnspr4.so.0db62f9000-b62fb000 rw-p 00000000
00:00 0b62fb000-b62fe000 r-xp 00000000 08:01 5038203
/usr/lib/libplc4.so.0db62fe000-b62ff000 rw-p 00002000 08:01 5038203
/usr/lib/libplc4.so.0db62ff000-b6301000 r-xp 00000000 08:01 5038204
/usr/lib/libplds4.so.0db6301000-b6302000 rw-p 00001000 08:01
5038204 /usr/lib/libplds4.so.0db6302000-b63ed000 r-xp 00000000
08:01 1750476 /usr/lib/libX11.so.6.2.0b63ed000-b63f1000 rw-p
000ea000 08:01 1750476 /usr/lib/libX11.so.6.2.0b63f1000-b63f9000
r-xp 00000000 08:01 1750604
/usr/lib/libXrender.so.1.3.0b63f9000-b63fa000 rw-p 00007000 08:01
1750604 /usr/lib/libXrender.so.1.3.0
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
25 de 41 13/01/2014 04:16 p.m.
-
b63fa000-b64ae000 r-xp 00000000 08:01 1749982
/usr/lib/libglib-2.0.so.0.1600.6b64ae000-b64af000 rw-p 000b4000
08:01 1749982 /usr/lib/libglib-2.0.so.0.1600.6b64af000-b64ea000
r-xp 00000000 08:01 1749979
/usr/lib/libgobject-2.0.so.0.1600.6b64ea000-b64eb000 rw-p 0003b000
08:01 1749979 /usr/lib/libgobject-2.0.so.0.1600.6b64eb000-b6515000
r-xp 00000000 08:01 1750090
/usr/lib/libfontconfig.so.1.3.0b6515000-b6516000 rw-p 0002a000
08:01 1750090 /usr/lib/libfontconfig.so.1.3.0b6516000-b6587000 r-xp
00000000 08:01 1749996
/usr/lib/libfreetype.so.6.3.18b6587000-b658b000 rw-p 00070000 08:01
1749996 /usr/lib/libfreetype.so.6.3.18b658b000-b65c9000 r-xp
00000000 08:01 5038105
/usr/lib/libpango-1.0.so.0.2002.3b65c9000-b65cb000 rw-p 0003d000
08:01 5038105 /usr/lib/libpango-1.0.so.0.2002.3b65cb000-b65f1000
r-xp 00000000 08:01 5038107
/usr/lib/libpangoft2-1.0.so.0.2002.3b65f1000-b65f2000 rw-p 00026000
08:01 5038107 /usr/lib/libpangoft2-1.0.so.0.2002.3b65f2000-b665c000
r-xp 00000000 08:01 5038093
/usr/lib/libcairo.so.2.17.5b665c000-b665e000 rw-p 0006a000 08:01
5038093 /usr/lib/libcairo.so.2.17.5b665e000-b6667000 r-xp 00000000
08:01 5038106
/usr/lib/libpangocairo-1.0.so.0.2002.3b6667000-b6668000 rw-p
00008000 08:01 5038106
/usr/lib/libpangocairo-1.0.so.0.2002.3b6668000-b66a7000 r-xp
00000000 08:01 5038374
/usr/lib/libhunspell-1.2.so.0.0.0b66a7000-b66ab000 rw-p 0003e000
08:01 5038374 /usr/lib/libhunspell-1.2.so.0.0.0b66ab000-b66bf000
r-xp 00000000 08:01 1747421
/usr/lib/libz.so.1.2.3.3b66bf000-b66c0000 rw-p 00013000 08:01
1747421 /usr/lib/libz.so.1.2.3.3b66c0000-b66d1000 r-xp 00000000
08:01 5038211 /usr/lib/libnssutil3.so.1db66d1000-b66d4000 rw-p
00011000 08:01 5038211 /usr/lib/libnssutil3.so.1db66d4000-b67a3000
r-xp 00000000 08:01 5038210 /usr/lib/libnss3.so.1db67a3000-b67a7000
rw-p 000cf000 08:01 5038210 /usr/lib/libnss3.so.1db67a7000-b67c3000
r-xp 00000000 08:01 5038212
/usr/lib/libsmime3.so.1db67c3000-b67c5000 rw-p 0001c000 08:01
5038212 /usr/lib/libsmime3.so.1db67c5000-b67ea000 r-xp 00000000
08:01 5038213 /usr/lib/libssl3.so.1db67ea000-b67ec000 rw-p 00025000
08:01 5038213 /usr/lib/libssl3.so.1db67ec000-b687c000 r-xp 00000000
08:01 1747488 /usr/lib/libmozjs.so.1db687c000-b6881000 rw-p
0008f000 08:01 1747488 /usr/lib/libmozjs.so.1db6881000-b68b1000
r-xp 00000000 08:01 5038370
/usr/lib/liblcms.so.1.0.16b68b1000-b68b2000 rw-p 00030000 08:01
5038370 /usr/lib/liblcms.so.1.0.16b68b2000-b68b5000 rw-p 00000000
00:00 0b68b5000-b68d8000 r-xp 00000000 08:01 1750030
/usr/lib/libpng12.so.0.27.0b68d8000-b68d9000 rw-p 00023000 08:01
1750030 /usr/lib/libpng12.so.0.27.0b68d9000-b68f7000 r-xp 00000000
08:01 1749812 /usr/lib/libjpeg.so.62.0.0b68f7000-b68f8000 rw-p
0001e000 08:01 1749812 /usr/lib/libjpeg.so.62.0.0b68f8000-b6965000
r-xp 00000000 08:01 1749005
/usr/lib/libsqlite3.so.0.8.6b6965000-b6967000 rw-p 0006c000 08:01
1749005 /usr/lib/libsqlite3.so.0.8.6b6967000-b73d9000 r-xp 00000000
08:01 1893684 /usr/lib/xulrunner-1.9/libxul.sob73d9000-b74b6000
rw-p 00a72000 08:01 1893684
/usr/lib/xulrunner-1.9/libxul.sob74b6000-b74c6000 rw-p 00000000
00:00 0b74c6000-b74d2000 r-xp 00000000 08:01 2949164
/lib/libgcc_s.so.1b74d2000-b74d3000 rw-p 0000b000 08:01 2949164
/lib/libgcc_s.so.1b74d3000-b74f7000 r-xp 00000000 08:01 2958656
/lib/i686/cmov/libm-2.7.sob74f7000-b74f9000 rw-p 00023000 08:01
2958656 /lib/i686/cmov/libm-2.7.sob74f9000-b764e000 r-xp 00000000
08:01 2958652 /lib/i686/cmov/libc-2.7.sob764e000-b764f000 rp
00155000 08:01 2958652 /lib/i686/cmov/libc-2.7.so
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
26 de 41 13/01/2014 04:16 p.m.
-
b764f000-b7651000 rw-p 00156000 08:01 2958652
/lib/i686/cmov/libc-2.7.sob7651000-b7655000 rw-p 00000000 00:00
0b7655000-b7738000 r-xp 00000000 08:01 1745058
/usr/lib/libstdc++.so.6.0.10b7738000-b773b000 rp 000e2000 08:01
1745058 /usr/lib/libstdc++.so.6.0.10b773b000-b773d000 rw-p 000e5000
08:01 1745058 /usr/lib/libstdc++.so.6.0.10b773d000-b7743000 rw-p
00000000 00:00 0b7743000-b7745000 r-xp 00000000 08:01 2958655
/lib/i686/cmov/libdl-2.7.sob7745000-b7747000 rw-p 00001000 08:01
2958655 /lib/i686/cmov/libdl-2.7.sob7747000-b7749000 r-xp 00000000
08:01 1804257
/usr/lib/pango/1.6.0/modules/pango-basic-fc.sob7749000-b774a000
rw-p 00001000 08:01 1804257
/usr/lib/pango/1.6.0/modules/pango-basic-fc.sob774a000-b774c000
r-xp 00000000 08:01 5038147
/usr/lib/libavahi-glib.so.1.0.1b774c000-b774d000 rw-p 00002000
08:01 5038147 /usr/lib/libavahi-glib.so.1.0.1b774d000-b7754000 r-xp
00000000 08:01 2958659
/lib/i686/cmov/libnss_compat-2.7.sob7754000-b7756000 rw-p 00006000
08:01 2958659 /lib/i686/cmov/libnss_compat-2.7.sob7756000-b7759000
r-xp 00000000 08:01 1893677
/usr/lib/xulrunner-1.9/libxpcom.sob7759000-b775a000 rw-p 00002000
08:01 1893677 /usr/lib/xulrunner-1.9/libxpcom.sob775a000-b775c000
rw-p 00000000 00:00 0b775c000-b775d000 r-xp 00000000 00:00 0
[vdso]b775d000-b7777000 r-xp 00000000 08:01 2949122
/lib/ld-2.7.sob7777000-b7779000 rw-p 0001a000 08:01 2949122
/lib/ld-2.7.sobfce1000-bfd17000 rw-p 00000000 00:00 0 [stack]
Layout of a program in memory | Complete Coding on January 5th,
2010 9:55 am
[...] area is a read only area of memory.You can learn more
details about the anatomy of programmemory, here.Technorati Tags:
virtual file system, paging, layout of program memory
RelatedPosts:Modular [...]
96.
Ashish on January 10th, 2010 11:08 am
Very Nice post good effort, thanks a lot for such a valuable
information. I have a query.If a program define 5GB of a static
variable, where it will go since process have only 4GB block
ofvirtual memory addresses in 32-bit mode.
97.
Interesting Reading The Blogs at HowStuffWorks on January 11th,
2010 11:09 am
[...] Anatomy of a program in memory Memory management is the
heart of operating systems; it iscrucial for both programming and
system administration. In the next few posts Ill cover memory
withan eye towards practical aspects, but without shying away from
internals. While the concepts aregeneric, examples are mostly from
Linux and Windows on 32-bit x86. This first post describes
howprograms are laid out in memory. [...]
98.
mike on February 4th, 2010 2:11 am
good writing and thanks for your sharing.
99.
joey on March 24th, 2010 2:05 am
Please forgive my ignorance or immaturity on this subject, Ive
been reading on it for the past 2 weeksand I get confusing
information about the elf.
100.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
27 de 41 13/01/2014 04:16 p.m.
-
I did a hexdump >>hexdump -C in my linux machine on my
elf(executable) and I was able to traceout the different sections
and segments with the hexdump >>readelf -x .text . Now the
hexdump fromthe 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 like008048540. Please help clarify
things, I dont believe in magic. I also read that section .symtab
is notincluded 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..
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. Maybeyou 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 linesper 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 Inoticed 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) seemsvery 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.6b76e1000-b76e2000 p 00036000 08:02 127570
/lib/libncurses.so.5.6b76e2000-b76e4000 rp 00036000 08:02 127570
/lib/libncurses.so.5.6b76e4000-b76e8000 rw-p 00038000 08:02 127570
/lib/libncurses.so.5.6
Stphane
101.
Sudheer on May 24th, 2010 8:12 am102.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
28 de 41 13/01/2014 04:16 p.m.
-
Hi Guru,
A basic question.Is there any difference in generation of
logical addresses for a program in linux OS and windows OS?
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 ididnt get it and this time also.
(Dont mind author bcoz my knowledge in hardware functionality
isvery poor) But definitely this post will useful for tech savvy
guys
103.
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
AddressSpace.
I couldnt help not thank you for this article.
Thanks a lot,Shobhit
104.
JAT on July 1st, 2010 5:05 am
Excellent Work
105.
Super on July 6th, 2010 7:35 pm
Pretty cool, thank you for your great job! It really helps me a
lot.
106.
chaitanya on July 9th, 2010 10:57 am
Thanks for the in-detailed article
107.
Anty on July 10th, 2010 1:26 am
Pretty Cool, THX very much
108.
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 forthis memory
mapping, really this will give great insight for beginners,
Thanks,Nandu
109.
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 ofmemory addresses.
110.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
29 de 41 13/01/2014 04:16 p.m.
-
Manish on September 27th, 2010 6:59 am
Ya,very good content .can you explain little bit more about
anonymous memory and malloc()relation with it.That will surely
provide more knowledge to beginner .
111.
Linux memory management 32-bit x86 Stack0verflow on October
30th, 2010 11:08 am
[...] [2]: Understanding the Linux Kernel By Daniel Pierre
Bovet, Marco Cesat [3]: man pages
[4]:http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
by Gustavo Duarte [5]:http://wikipedia.org/ [6]:
http://lxr.linux.no/ [7]:http://linux-mm.org/ [...]
112.
Girish on November 23rd, 2010 12:13 am
This is really nice.
Thanks-Girish
113.
apj on November 23rd, 2010 1:12 pm
Thanks for the awesome article! There is one thing im unable to
understand.. what goes into the I GBkernel space?. and what about
kernel processes?.
114.
Sashi on December 5th, 2010 9:14 pm
This is a great article! very well presented and making things
crystal clear.
Thanks! and looking forward for more
115.
Web Developer on February 12th, 2011 2:55 am
I can remember doing the fetch-execute cycle at college, could
never remember it! But this is so muchdeeper!
Web Developer
116.
A collection of articles on virtual memory kwoz online on March
22nd, 2011 8:10 am
[...] Here is a rather interesting article on virtual memory
from operating systems point of view. Itappears to link to other
posts on similar topics, including processor privileges. Low-level
but could behandy. GA_googleAddAttr("AdOpt", "1");
GA_googleAddAttr("Origin", "other");GA_googleAddAttr("theme_bg",
"ffffff"); GA_googleAddAttr("theme_border",
"000000");GA_googleAddAttr("theme_text", "000000");
GA_googleAddAttr("theme_link",
"2970A6");GA_googleAddAttr("theme_url", "2970A6");
GA_googleAddAttr("LangId", "1");GA_googleAddAttr("Autotag",
"technology"); GA_googleFillSlot("wpcom_below_post");
Categories:Uncategorized LikeBe the first to like this post.
Comments (0) Trackbacks (0) Leave a commentTrackback [...]
117.
UbuntuGuy on March 26th, 2011 12:13 pm
Great article, very inspiring. make me wanna take out the old c
book and start kernel programming
118.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
30 de 41 13/01/2014 04:16 p.m.
-
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 formanaging user memory. Here is
gonzo [...]
119.
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 for4GB memory.
Question is:When MMU translate the linear address to physical
address it requires Page Global directory table andPage Table
array, from where it gets that? because PGD and PTE arrays are
located itself in physicalmemory
120.
Harold Wang on May 25th, 2011 7:55 am
Amazing Job! Thank you!
121.
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 ??
122.
Pravin on July 3rd, 2011 8:27 am
Thanks heaps!
123.
PHP 64- ? ! :: on July 12th, 2011 11:07 pm
[...] [...]
124.
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 outexecutables and shared
libraries within the process address space and how it creates
sharedmemory regions. Two core abstractions of every modern OS
[...]
125.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
31 de 41 13/01/2014 04:16 p.m.
-
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 inLinux by Aitor Pazos. Bookmark the
permalink. [...]
126.
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 thestring that the pointer gonzo points to Gods
own prototype is in text segment and isread-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?
127.
David on September 15th, 2011 8:47 am
Great post, (with the virtual address layout) why is [00,
008048000) left unmapped? Is it ano-touching region? Any
reason?
128.
Mars on September 22nd, 2011 7:43 pm
Hi Gustavo DuarteThanks 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.
129.
Anatomy of a Program in Memory : Gustavo Duarte | FRANCESCO DI
FUSCO on October 31st, 20111:43 am
[...] Anatomy of a Program in Memory : Gustavo Duarte.
Sharethis:TwitterFacebookStumbleUponPrintEmailLinkedInLike
this:LikeBe the first to like this post. Thisentry was posted in
Linux, Operating Systems by francescodifusco. Bookmark the
permalink. [...]
130.
Ramachandra on November 15th, 2011 3:16 am
Wonderful article It helped me to regain my position in Indias
3rd largest IT company.
131.
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 otherposts of yours.. really
informative!!
132.
From 090 to 0x4c454554, a journey into exploitation Mr.Anubis's
Blog on November 29th, 20117:23 pm
[...] Anatomy of a program in memory [...]
133.
Anon on December 7th, 2011 6:32 pm
Great article! Thanks.
134.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
32 de 41 13/01/2014 04:16 p.m.
-
I have a query. The figure you have shown is when you have a
single process. When there are say 2processes, how will the memory
layout be? I understand as below from top of memory to
bottom1)kernel space(1 gb) same2) all other sections gets split for
p1, p2 say of size 3gb/2
Please correct me if i am wrong.
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 aSegmentation Fault. This
helps prevent pointer bugs
Does it mean that the text segment contains code to make an
additional mapping of the entire binaryfile (in addition to the BSS
and data segments as explained earlier in the article)?
Also, how do this prevent pointer bugs?
Brs,Markus
135.
kishor kunal on January 17th, 2012 12:21 am
very nice .thank u dude.
136.
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.
137.
()-ld_brk_pointbrk-Sigma on April 9th, 2012 6:05 am
[...]http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
[...]
138.
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
139.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
33 de 41 13/01/2014 04:16 p.m.
-
linuxswap [...]
How Does a Startup Out-recruit Google How Google Indexes the Web
Code Retreat and What WasLearnt in 45 Minutes Flipkart Slideshow
Banner Anatomy of a Program in Memory What Is and WhyOctopress ?
Welcome ! CSS Tips on April 28th, 2012 1:48 am
[...] Memory management is the heart of operating systems; it is
crucial for both programming andsystem administration. Gustavo
Duarte, duartes.org/gustavo/blog/post/ [...]
140.
How Does a Startup Out-recruit Google How Google Indexes the Web
Code Retreat and What WasLearnt in 45 Minutes Flipkart Slideshow
Banner Anatomy of a Program in Memory What Is and WhyOctopress ?
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 undergraduatestudent Memory management is
the heart of operating systems; it is crucial for both programming
andsystem administration. Gustavo Duarte,
duartes.org/gustavo/blog/post/ [...]
141.
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.
142.
Allen on May 23rd, 2012 4:29 pm
Thanks! Provided exactly what I was looking for
143.
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 forunderstanding 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
144.
Blog Archive on June 9th, 2012 2:26 am
[...]http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
[email protected] /* */ [...]
145.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
34 de 41 13/01/2014 04:16 p.m.
-
Prashant on June 17th, 2012 10:48 am
Really very written article. Thanks for the valuable information
shared.
146.
chandu on July 4th, 2012 5:12 am
Very use full information. Thanks a lot.
147.
Kuro on August 2nd, 2012 3:54 pm
Very well written article!Can you comment what VSZ of ps or VIRT
of top value represent ? I would like to know how muchheap memory
my program is consuming. How can I figure it out?
148.
Ranga Tirumalaseti on September 8th, 2012 1:20 pm
Great Stuff. Explained in very effective manner.
Thank you for sharing knowledge.
An article relatede to Multithreaded programs and memory
allocationswill be great.
149.
Excelente artigo sobre memory management Bit is Myth on
September 28th, 2012 11:45 am
[...] o artigo aqui. Share this:EmailTwitterFacebookGostar
disso:GosteiSeja o primeiro a gostar disso.Deixe um [...]
150.
abhi on October 8th, 2012 7:24 am
Thank you. Great post!
One confusion, doesnt malloc in libc use the heap? Or does it
depend on the allocator used?
151.
Hanwen Wu on October 15th, 2012 10:50 am
Awesome! Thank you for all your articles about memory. Those
figures are really helpful forunderstanding those complex things.
Thank you!
152.
sena on November 4th, 2012 12:04 pm
Beautiful diagrams. Im a kind of visual learner. I got your page
by image search linux processmemory model. As most of the people
commented early, some of the information I read here is verynew and
gets me more insight into Linux system. Thanks for your time and
good work.
153.
Arun Perumal on November 21st, 2012 3:07 am
Thanks a lot for the article. This one, clears one of my long
standing doubt/confusion about kernelspace addresses across all the
processes. I had the question raised on stack overflow, and
finallymyself updated a answer with clarification based on your
article.http://stackoverflow.com/questions/12995957/linux-kernel-logical-address-for-multiple-processes
154.
static variable initialization on November 21st, 2012 1:22
pm155.
Anatomy of a Program in Memory : Gustavo Duarte
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
35 de 41 13/01/2014 04:16 p.m.
-
[...] (excluding some embedded ones) use virtual memory mapping.
Check out this link for anoverview: Anatomy of a Program in Memory
: Gustavo Duarte. Google "linux process memory layout"for more
examples and info of how Linux does it. [...]
nadji on November 30th, 2012 1:58 pm
it is the better tutorial thank you
156.
leo kirotawa on January 10th, 2013 11:19 am
Great blog and article =). Im trying find a good material about
that. Thanks a lot!
157.
abhishek on January 12th, 2013 12:53 pm
I have some confusion with respect to what you postedyou mention
Each process in a multi-tasking OS runs in its own memory sandbox.
This sandbox is thevirtual 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 ofdiagram.
Also what do stack and heap contain in case of a running
program?
158.
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) Wh