Re: Looking for known memory leaks ... [ISOLATED?]

["Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>]

On Thu, 18 Feb 2021, Lennart Poettering wrote:

> On Do, 18.02.21 11:48, Robert P. J. Day (rpjday@xxxxxxxxxxxxxx) wrote:
>
> >   A colleague has reported the following apparent issue in a fairly
> > old (v230) version of systemd -- this is in a Yocto Project Wind River
> > Linux 9 build, hence the age of the package.
> >
> >   As reported to me (and I'm gathering more info), the system was
> > being put through some "longevity testing" by repeatedly adding,
> > removing, activating and de-activating network interfaces. According
> > to the report, the result was heap space slowly but inexorably being
> > consumed.
> >
> >   While waiting for more info, I'm going to examine the commit log for
> > systemd from v230 moving forward to collect any commits that address
> > memory leaks, then peruse them more carefully to see if they might
> > resolve the problem.
> >
> >   I realize it's asking a bit for folks here to remember that far
> > back, but does this issue sound at all familiar? Any pointers that
> > might save me some time? Thanks.
>
> Note that our hash tables operate with an allocation cache: when
> adding entries to them and then removing them again the memory
> required for that is not returned to the OS but added to a local
> cache. When the next entry is then added again, we recycle the
> cached entry instead of asking for new memory again. This allocation
> cache is a bit quicker then going to malloc() all the time, but
> means if you just watch the heap you'll assume there's a leak even
> though there isn't really, the memory is not lost after all, and
> will be reused eventually if we need it.

  For what it's worth, I thought people might like to know what
appears to be the problem. A couple colleagues isolated it to repeated
invocations of the command:

  $ systemctl status $$

  They wrote a tight loop that just kept calling that command, and
checking memory usage, and it kept going up. Wind River confirms they
see the same behaviour. I figured that since I had asked for
assistance, people might want to know where the eventual problem seems
to lie, even if it's for a really ancient version of systemd.

rday
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel