Oron Peled wrote:
On Friday, 2 בMay 2008, Shachar Shemesh wrote:
Re Choo's comment about memory available through "malloc" working for
him - malloc uses "brk(2)" to allocate memory as long as it possibly
can.
That was what I always thought. However, I found out lately
that uclibc (in which you can compile one of three different
allocators) uses mmap *exclusively* for heap management
How exclusively?
For example, if I "free" a piece of memory, does it do "munmap" on it?
The standard way is to only ask the kernel for more memory where
applicable, never return anything (at least so long as you are in the
brk area). You manage the memory inside that area using heap or tree or
some other data structure. This is also the reason that heap overflows work.
Which brings me to another point - if you use electric fence, that also
uses mmap for memory allocation (it creates "hot spots" - areas where
accessing the memory around the memory you allocated triggers a segfault).
(which makes a lot of sense for MMU-less machines).
Then again, machines with no MMU will rarely have enough memory to
justify a pointer being sign extended to a negative number. As the
memory is, usually, found toward the lower addresses, and as the machine
has no MMU to move it anywhere else, that problem wouldn't have happened
there either :-)
I haven't read the code of glibc allocator so I'm not sure about the
exact rules. However, a cursory test (just a single malloc() in an empty
program) has demonstrated (via strace) that the sky is not falling
yet and your assertion about brk(2) remains true in the normal world.
Wine used to suffer greatly from that. Because of the weird addresses
(for Linux) that Wine loads the executables and places the stack, brk
has no free space to work with, and the command is unable to return any
memory. mmap, on the other hand, could not allocate random memory (i.e.
- when you do not tell it where to allocate) from the lower 1GB of the
virtual address space (presumably, so it will leave space for brk to
work). Then again, most Windows programs are written for the
non-advanced version of Windows, that has a 2/2 split between user space
and kernel space. As such, Wine takes care not to let them receive
memory above the 2GB mark. As a result, for most programs, Wine only had
1GB of memory it can allocate to you before it runs out. Like I said, I
don't know whether that's still the case.
Shachar
================================================================To unsubscribe,
send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
