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

Previous Next

Full log

Message #317 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, Jean Louis <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 18:19:32 +0100

> The glibc malloc is the prime suspect anyway.  I don't really believe Emacs had
> such a glaring memory leak.

This has to be something introduced fairly recently, right?

I didn't have any such problems before, but since maybe few weeks ago, I
have also experienced heavy lockdowns of my entire OS. To the point
where entire X11 got unresposnsive, when it happens I can't even switch
to terminal to kill Emacs. What I do is Alt-Shift to another virtual
linux console. I don't even need to log into the system in that console,
I can then Alt-Shift 1 to go back to one I am logged into, and
everything is normal. Emacs is every time restarted by systemd and
everything is repsonsive and working as normal. 

This started sometime ago; and I have noticed that it happens when I was
cleaning my disk and reading big directories in Dired (I have some with
~7k-10k files in them). I was using Helm to complete paths when I was
shifting fiels and folders around. After maybe hour or so I would
experience big slowdown. I don't have swap file on my system enabled at
all, so I am not sure what was going, but I didn't have time to
participate in this memory leak thing yet. I haven't experienced any
problems since I recompiled Emacs last time, which was in 18th (last
Wendesday). I have recompiled without Gtk this time, but I have no idea
if it has anything to do with the issue, was just a wild shot to see if
things are better.

Previous Next

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