Re: [LONGish] Brief analysis of VMAs (was: /proc/<n>/maps getting

[David Luyer <david_luyer@pacific.net.au>]

On 06 Aug 2001 14:05:52 +0100, Alan Cox wrote:
> > Yes, that's what's happening above.  And it's what's causing the
> > splits in the vmas.  So basically evolution-mail is doing exactly what
> > your test program was doing, and causing exactly the same thing.
> > 
> > Seems strange that glibc would do this unless there was some performance
> > reason on past kernels to do it?
> 
> Are you sure thats not evolution being built with a debugging malloc of
> some kind ?

Yes, as per cw's e-mail it's just how malloc() works in some cases on
glibc.  Allocate 2 * sz (where sz is a relatively large amount compared
to the amount being malloc()'d), free up the 'sz' which is not aligned
to a multiple of 'sz', and the gradually mprotect(PROT_READ|PROT_WRITE)
the memory it's allocated initially with PROT_NONE and MAP_NORESERVE.

And mprotect() responds by splitting up the vmas and never merging them
back together.
-- 
David Luyer                                     Phone:   +61 3 9674 7525
Engineering Projects Manager   P A C I F I C    Fax:     +61 3 9699 8693
Pacific Internet (Australia)  I N T E R N E T   Mobile:  +61 4 1111 2983
http://www.pacific.net.au/                      NASDAQ:  PCNTF