Zsh Mailing List Archive
Messages sorted by:
Re: compsys maps anonymous memory and never frees it
- X-seq: zsh-users 13193
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-users@xxxxxxxxxx
- Subject: Re: compsys maps anonymous memory and never frees it
- Date: Thu, 04 Sep 2008 07:25:26 -0700
- In-reply-to: <682f90440809031604j5e349af2q8d40f24fc429dcc3@xxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <48BDF1EC.4050204@xxxxxxxxx> <080902200652.ZM9887@xxxxxxxxxxxxxxxxxxxxxx> <682f90440809031604j5e349af2q8d40f24fc429dcc3@xxxxxxxxxxxxxx>
On Sep 4, 1:04am, =?ISO-8859-1?Q?Bj=F6rn_Herzig?= wrote:
} I looked at the problem a little closer. Zsh does not call mmap to
} allocate them and they dont get allocated when completion happens but
} when the next command gets issued.
If this is true, then this is something happening down in the library
or kernel implementation of fork() and is out of zsh's control.
Did you build zsh yourself? Can you check config.h for USE_MMAP ?
If USE_MMAP is defined then anytime zsh parses a command it will have
called mmap() to allocate zsh-heap space. You can try reconfiguring
with --enable-zsh-mem and then check the pmap behavior again.
} So in my example the new maps got added to the process' address space
} when i executed pmap, but the same happens with any other programm.
} Builtins however are an exception. So things start to go wrong when it
} comes to forking.
If you run pmap from another shell window rather than executing it
from within the shell whose map you're examining, does the behavior
change at all?
My only guess goes something like this:
Zsh has mapped memory for the heap during parsing etc. Those pages
have had data written and therefore are marked "dirty". When fork()
is called, those pages become shared address space with the child
process. Zsh munmap()s them later but they aren't returned to the
system because the child process is still using them.
I'm not really happy with any of these explanations yet.
Messages sorted by: