Re: [PATCH] compsys maps anonymous memory and never frees it

["xRaich[o]²x" <raichoo@xxxxxxxxxxxxxx>]

Andrey Borzenkov wrote:
> On Sunday 07 September 2008, xRaich[o]²x wrote:
>   
> > Bart Schaefer wrote:
> >     
> > > 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.
> > >
> > >       
>
> I was able to more or less reproduce it on Linux; but now after your patch
> I get what looks like memory leak. Here are heaps after several memory
> intensive completions:
>
> Address   Kbytes     RSS    Anon  Locked Mode   Mapping
> 08048000     608       -       -       - r-x--  zsh
> 080e0000      16       -       -       - rw---  zsh
> 080e4000      92       -       -       - rw---    [ anon ]
> 09d6a000     672       -       -       - rw---    [ anon ]
>
> [...]
>
> Address   Kbytes     RSS    Anon  Locked Mode   Mapping
> 08048000     608       -       -       - r-x--  zsh
> 080e0000      16       -       -       - rw---  zsh
> 080e4000      92       -       -       - rw---    [ anon ]
> 09d6a000    5340       -       -       - rw---    [ anon ]
> b6a68000   15464       -       -       - rw---    [ anon ]
>
>
> Compare this with version without patch:
>
> Address   Kbytes     RSS    Anon  Locked Mode   Mapping
> 08048000     528       -       -       - r-x--  zsh
> 080cc000      16       -       -       - rw---  zsh
> 080d0000      88       -       -       - rw---    [ anon ]
> 099df000     744       -       -       - rw---    [ anon ]
>
> [...]
>
> Address   Kbytes     RSS    Anon  Locked Mode   Mapping
> 08048000     528       -       -       - r-x--  zsh
> 080cc000      16       -       -       - rw---  zsh
> 080d0000      88       -       -       - rw---    [ anon ]
> 099df000    5520       -       -       - rw---    [ anon ]
> b6adb000   15464       -       -       - rw---    [ anon ]
> b7a05000      12       -       -       - rw---    [ anon ]
> b7b46000     108       -       -       - rw---    [ anon ]
>
> So it looks like we still have some memory leak somewhere. 
>   
Are you sure that those segments aren't those dlopen allocates when 
loading modules? they are actually created by the operating system and 
needed.

What i find a bit disturbing is that whenever loading modules one 
segment gets unmapped by munmap with two times its size. I think the 
operating system will catch that but maybe this is possible to fix 
somehow. i wrote a little dtrace script that keeps track of every mapped 
segment and checks if they get munmapped with the correct size. 
Everything except the mentioned munmap seems to work after the patch.

Regards,
Björn