bug#49656: more data on #43389

[Madhu]

*  Eli Zaretskii <eliz@gnu.org> <83o8ax5hxp.fsf@gnu.org>
Wrote on Tue, 20 Jul 2021 14:43:46 +0300

>> This is the emacs memory bloat issue. I thought I had unarchived the
>> bug earlier but it seems to be closed up again. Should I open a new
>> bug? Its already got a 1000 posts on the bugzilla page
> I'm not yet sure this is a bug, FWIW.

It's been bugging me for a few years now, but I won't mind if you
close it.

>> Over the past few months, I've experienced the memory problem a few
>> times.  I wanted to share the malloc info data I collected on 3
>> instance and am attaching a tarball with 3 directories named 4 5 6
>> which include malloc-info, memory-usage, and memory-report data from
>> emacs exhibiting the behaviour - after all buffers are killed and
>> after an M-x gc.
>> Directories 4 and 6 show the common pattern where memory is used
>> unknown to GC. data in directory 5 probably another issue where there
>> are a lot of dead strings.
> I've looked at the data, thanks.  But the most important information
> is missing from the data you presented.  The case where you have 570MB
> in strings could be interesting, but without knowing what you did in
> that session, it is impossible to say whether there's an issue there.
> It could be explained by the live Lisp data you produced in that
> session.

That 570MB case was the exceptional case - i noticed that only
once.

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.

> 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.

>   . 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.

>   . 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. All the recent reports are on
Emacs 28, within a month of two of master.  The problem is independent
of the toolkit, I get it in motif, gtk, and xt.  I havent tried a no-x
build in 2 years.

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

> In general, that old bug is closed, because after making a single
> change that did cause memory bloat in some usage patterns, we
> concluded that the rest were user problems caused by messing with GC
> thresholds.  The glibc developers looked at the data we collected
> and found nothing that could be interpreted as a bug in glibc.

But doesn't the malloc info allocation and the gc reports indicate a
clear discrepancy?  Does it not indicate a leak which the GC is not
aware of?