GNU bug report logs - #43389
28.0.50; Emacs memory leaks

Previous Next

Full log

Message #359 received at 43389 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, bugs <at> gnu.support, dj <at> redhat.com,
 michael_heerdegen <at> web.de, trevor <at> trevorbentley.com, carlos <at> redhat.com
Subject: Re: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Mon, 23 Nov 2020 20:38:45 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Arthur Miller <arthur.miller <at> live.com>
>> Cc: bugs <at> gnu.support,  fweimer <at> redhat.com,  43389 <at> debbugs.gnu.org,
>>   dj <at> redhat.com,  michael_heerdegen <at> web.de,  trevor <at> trevorbentley.com,
>>   carlos <at> 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 <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.