Re: Understanding Linux addr space, malloc, and heap

["Vincent W. Freeh" <vin@csc.ncsu.edu>]

Thanks for your quick response.  It basically confirmed that I observed 
what I thought I did.  However, I am no closer to solving my problem.  I 
cannot mprotect data that I malloc beyond the first 65 pages.  Why is 
that?  Can that be fixed?  Second, why does mprotect silently fail?  I 
could live with it failing--but I cannot deal with a call the "works" 
but doesn't work.

Thanks,
vince.

-----------
Subject	Re: Understanding Linux addr space, malloc, and heap
From	Arjan van de Ven <>
Date	Fri, 21 Oct 2005 15:00:02 +0200

On Fri, 2005-10-21 at 08:46 -0400, Vincent W. Freeh wrote:
 > I am trying to understand the Linux addr space.  I figured someone might
 > be able to shed some light on it.  Or at least point me to some sources
 > that will help.
 >
 > I don't understand what is happening with malloc and the heap in my
 > process. According to /proc/<pid>/maps the memory from heap to stack
 > initially looks like that.  I only show the four "maps" from the heap
 > and above.  (This is a slightly altered form consisting of start_addr,
 > end_addr, size_in_pgs, permissions, and path_if_one):
 >
 > 0x08d42000 - 0x08d63000 (33 pgs) rw-p   path `[heap]'
 > 0xb7ef8000 - 0xb7ef9000 (1 pgs) rw-p
 > 0xb7f09000 - 0xb7f0b000 (2 pgs) rw-p
 > 0xbfaf5000 - 0xbfb0b000 (22 pgs) rw-p   path `[stack]'
 >
 > First, please fix any erroneous statements/assumptions above.  Next I
 > have many questions.  A few follow.
 >
 > * How does the heap work?  I learned/teach that heap is a contiguous
 > chunk of memory that holds dynamically-allocated memory.  Doesn't appear
 > to be the case.

that's the old school 1970's stuff

the "heap" is still brk in linux, however there is no 1:1 relation
between heap and malloc. malloc in glibc is implemented both using brk
and mmap, depending on the size of your allocation.


 >
 > * Man pg says can only mprotect mmap-able pages.  But what are these?
 > How can I tell?

you need to mmap these yourself to be sure.. eg you cannot mprotect the
output of malloc, at least not reliably. Only of mmap.

 >
 > * Why does mprotect silently fail?

no it has sideeffects; eg it most likely affects more memory than just
your malloc()'d part


 > * I thought brk indicated the top of the heap and that all dynamic
 > memory would be between bss end and brk.  That's not true.  What is brk
 > for then?

see definition of heap vs malloc above