bug#43389: 28.0.50; Emacs memory leaks using hard disk all time

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: bugs@gnu.support,  fweimer@redhat.com,  43389@debbugs.gnu.org,
>>   dj@redhat.com,  michael_heerdegen@web.de,  trevor@trevorbentley.com,
>>   carlos@redhat.com
>> Date: Mon, 23 Nov 2020 19:40:23 +0100
>> 
>> > That doesn't sound like a memory problem to me.
>> Ok; acknowledged; any idea what it could be?
>
> Actually, I take that back: it does look like the OOM killer that
> killed Emacs:
>
>   nov 17 16:32:44 pascal kernel:
> oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service,task=emacs,pid=>
>   nov 17 16:32:44 pascal kernel: Out of memory: Killed process 605 (emacs)
> total-vm:29305960kB, anon-rss:29035892kB, file-rss:0kB, shmem-rss:5096kB,
> UID:1000 pgtables:57144kB oom_score_adj:0

>> I have attached you a syslog from one crash point, you can see Emacs
>> is using almost 8gig or RAM, but I have 32, so there is plenty of
>> unused RAM over.
Haha, I'm such a noob :-). You have eagle eye; I wasn't looking
carefully. I just looked at the process list which showed ~7 gig or ram.

> It says above that the total VM size of the Emacs process was 29GB,
> not 8.
>
> So maybe yours is the same problem after all.

> How about writing a simple function that reports the total VM size of
> the Emacs process (via process-attributes), and running it from some
> timer?  Then you could see how long it takes you to get from, say, 2GB
> to more than 20GB, and maybe also take notes of what you are doing at
> that time?
Ouch; I have to look up (process-attributes) in the info ... :-(. I
planned to do something else today, but I'll give it a look.

By the way; I haven't experienced this since 18th this month; day after
when I rebuild. So it has been almost 5 days without a crash. But I also
don't shift big folders any more; I cleanud up my old backup drive.
Is there some hefty ram-tasking benchmark with lots of random list
creations and deletions I could run; maybe some suitable ert-test
already written?