matthewn at snapgear.com
Tue Mar 25 00:59:59 EST 2003
Unfortunately you are correct. Rather than displaying your ignorance,
you are displaying my ignorance ;-). I colleague here pointed this out to me
At one point in the past we used to use mmap directly to implement
malloc. This had the side affect of simply inserting mmap entries into
the vfork child processes mm structure. Ergo when mm_release was
called, all your memory was freed.
This is not the case anymore. We now use a complicated malloc which
does big mmaps when required and then divvies up the space on individual
malloc calls. This means a malloc will now use memory from the parent as
you suggest. The memory will not be freed, and a little piece of memory
will be lost every time boa calls a CGI program.
Well spotted and sorry for the misdirect.
buc at larsen.st wrote:
> Thanks for your help.
> I'm using a very slightly modified MOTOROLA 5272C3 configuration. I don't
> think is_in_rom is the problem: addresses just above and just below are
> freed fine.
> Trawling the Linux source code backs up your statement. do_execve calls
> stuff which likely calls load_flat_file which calls exec_mmap which calls
> Allow me to display my ignorance by advancing a theory.
> Boa is doing a vfork() instead of a fork(). This means the child does not
> get a cloned memory space, but plays in the parent's memory space. This
> means that any malloc's the child does is done in the parent's memory space
> rather than the child's. Execve from the child just cleans up the child,
> not the parent. The memory is not freed until the parent is cleaned up,
> which in my case is never.
> please tell me I'm wrong.
> > Bryan,
> > An execve will clean up all of the memory for the current process. The
> > new process (in this case the cgi program) will replace the existing
> > process (in this case boa). It looks like the mmap structures are
> > freed from within load_flat_file which is called by do_execve
> > (eventually).
> > If you are finding that the memory is not freed, then it is a bug in
> > your platform. Check that your is_in_rom macro (called from
> > mmnommy/mmap.c) is defined properly. On m68knommu it is defined in
> > arch/m68knommu/mm/memory.c.
> > Cheers
> > Matt
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> This message was resent by uclinux-dev at uclinux.org
p: +61 7 3435 2805
f: +61 7 3891 3630
matthewn at SnapGear.com
Custom Embedded Solutions
More information about the uClinux-dev