bug#49656: more data on #43389

[Eli Zaretskii]

> Date: Tue, 20 Jul 2021 21:38:37 +0530 (IST)
> Cc: 49656@debbugs.gnu.org
> From: Madhu <enometh@meer.net>
> 
> In all other cases I hit the memory leak gc thinks it only has 200M
> while the process has 1.5 to 3.5 GB resident.
> 
> I don't see how this can  be a user error.

It could be if, for example, you are using packages or your own code
which plays with GC thresholds.  E.g., I'm told that lsp-mode does
that; are you per chance using it?

> > So what we need is the following, for each case separately:
> >   . the size of the memory footprint of the Emacs session
> 
> I have this data for a few runs.  The sizes from `ps' correspond
> exactly to what malloc info shows so i decided to omit it.

Ah, but gleaning this from the malloc info takes some time, so telling
the number explicitly will help making the report more easily
understandable.

> >   . how long was the Emacs session running since it started
> 
> 2-3 days usually. I always have to kill emacs because I cant suspend
> the OS to disk because all of it is resident.

How much memory and swap do you have there?  Can you enlarge the total
VM size (by enlarging swap) so that you could run Emacs longer when it
gets to such large sizes?

Btw, 1.5GB is not too large for several days worth of work.

> >   . what were the main activities in that session . do you have some
> >   customizations related to GC, and if you do, what are they . what
> >   Emacs version is that, and what are its configuration parameters
> >   and features compiled into it
> 
> I am not doing anything special with GC.

Are you sure no package you use does something like that?  What were
the values of GC thresholds when the memory was large?  Was the value
of gcs-done increasing with time, or did it stay put (which would be
an evidence that Emacs doesn't run GC at all)?  If GC was running, how
frequently did it run?  (You could answer the last question either by
looking at the rate of growth in gcs-done, or by setting
garbage-collection-messages non-nil, which will cause Emacs announce
ever GC in the echo area.)

> if you remember I asked on emacs-help once and you informed me of a GC
> fix and it fixed that problem.

But that problem was fixed, so it cannot possibly affect you now.  And
we found that problem because the user reported lack of GC cycles
after some point.

> But doesn't the malloc info allocation and the gc reports indicate a
> clear discrepancy?

Not to me, it doesn't.  It means the malloc arena holds to a lot of
memory that it cannot release to the OS, but it is known that this can
happen for certain patterns of memory allocation and deallocation.
You can find explanations of why this happens on the net.

> Does it not indicate a leak which the GC is not aware of?

No.  Emacs allocates a lot of memory for purposes other than Lisp
objects, and that memory is not visible to GC nor to memory-report.