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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Trevor Bentley <trevor <at> trevorbentley.com>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, bugs <at> gnu.support, dj <at> redhat.com, carlos <at> redhat.com, michael_heerdegen <at> web.de
Subject: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Wed, 25 Nov 2020 21:22:02 +0200

> From: Trevor Bentley <trevor <at> trevorbentley.com>
> Cc: bugs <at> gnu.support, fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org,
>  dj <at> redhat.com, michael_heerdegen <at> web.de, carlos <at> redhat.com
> Cc: 
> Date: Wed, 25 Nov 2020 20:06:21 +0100
> 
> > "Freed" in what sense? returned to glibc? 
> 
> I was referring to glibc malloc/free, but emacs internal 
> allocations would also be interesting.  It's a moot point, as I 
> don't think emacs supports it.  In short, the question is "what 
> has garbage-collect done?"  It prints the state of memory after it 
> is finished, but I have no idea if it has actually "collected" 
> anything.

GC always frees something, don't worry about that.  Your chances of
finding Emacs in a state that it has no garbage to free are nil.

> I just set garbage-collection-messages to non-nil and evaluated 
> (garbage-collect), and nothing was printed...

??? really?  That can only happen if memory-full is non-nil.  Is it?

> you are suggesting that it should print something to *Messages*,
> right?

No, in the echo area.  these messages don't go to *Messages*.

> I've never tried emacs's profiler.  I'll try that next time I do a 
> big garbage-collect and see what it shows.

That won't help in this case: GC is in C, and the profiler doesn't
profile C code that is not exposed to Lisp.

Previous Next

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