<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 22, 2021 at 8:22 AM Robert P. J. Day <<a href="mailto:rpjday@crashcourse.ca">rpjday@crashcourse.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 18 Feb 2021, Lennart Poettering wrote:<br>
<br>
> On Do, 18.02.21 11:48, Robert P. J. Day (<a href="mailto:rpjday@crashcourse.ca" target="_blank">rpjday@crashcourse.ca</a>) wrote:<br>
><br>
> >   A colleague has reported the following apparent issue in a fairly<br>
> > old (v230) version of systemd -- this is in a Yocto Project Wind River<br>
> > Linux 9 build, hence the age of the package.<br>
> ><br>
> >   As reported to me (and I'm gathering more info), the system was<br>
> > being put through some "longevity testing" by repeatedly adding,<br>
> > removing, activating and de-activating network interfaces. According<br>
> > to the report, the result was heap space slowly but inexorably being<br>
> > consumed.<br>
> ><br>
> >   While waiting for more info, I'm going to examine the commit log for<br>
> > systemd from v230 moving forward to collect any commits that address<br>
> > memory leaks, then peruse them more carefully to see if they might<br>
> > resolve the problem.<br>
> ><br>
> >   I realize it's asking a bit for folks here to remember that far<br>
> > back, but does this issue sound at all familiar? Any pointers that<br>
> > might save me some time? Thanks.<br>
><br>
> Note that our hash tables operate with an allocation cache: when<br>
> adding entries to them and then removing them again the memory<br>
> required for that is not returned to the OS but added to a local<br>
> cache. When the next entry is then added again, we recycle the<br>
> cached entry instead of asking for new memory again. This allocation<br>
> cache is a bit quicker then going to malloc() all the time, but<br>
> means if you just watch the heap you'll assume there's a leak even<br>
> though there isn't really, the memory is not lost after all, and<br>
> will be reused eventually if we need it.<br>
><br>
> You may use the env var SYSTEMD_MEMPOOL=0 to turn this logic off,<br>
> but not sure v230 already knew that env var.<br>
<br>
  well, we seem to have isolated the issue, here it is in a nutshell<br>
based on a condensed note i got from someone who tracked it down this<br>
weekend. the memory leak is triggered by:<br>
<br>
  $ ssh root@<target> -p 830 -s netconf   [830 = netconf over SSH]<br>
<br>
long story short, according to jemalloc profiling, there is a massive<br>
memory leak in DBUS code, </blockquote><div><br></div><div>Ok, give that data to whoever supports your system.. you are not giving us anything useful..</div><div>Now.. Can it have memory leaks ? yeah, it could, however I have reviewed the code (Admit a long time ago) and leaks on the systemd binaries are usually limited to error paths not exercised often and frankly in the path to extinction.</div><div><br></div><div>What you see most of time are not leaks in the code, but leaks in understanding of memory management techniques.</div><div><br></div></div></div>