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

Previous Next

Full log

View this message in rfc822 format

From: Trevor Bentley <trevor <at> trevorbentley.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, 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 20:06:21 +0100

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

> Then I don't think we will be able to understand what consumes 
> memory at such high rate without some debugging.  Have you 
> considered using breakpoints and collecting backtraces, as I 
> suggested earlier? 

Next up will be libmtrace, and then I can look into gdb.  It's 
going to be really noisy... we'll see how it goes.

> 
> So the result of GC shows only tells you how much of the memory 
> was freed but NOT returned to glibc, it doesn't show how much 
> was actually free'd. 
> 
>> I'm wondering how to figure out how much memory a call to 
>> (garbage-collect) has actually freed.  Possibly a sort of "dry 
>> run" where it performs the GC algorithm, but doesn't release 
>> any memory. 
> 
> "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.

>> As far as I understand, garbage collection is supposed to 
>> happen  automatically during idle.  I would certainly notice if 
>> it locked  up the whole instance for 10 minutes from an idle 
>> GC.  I think  this means the automatic garbage collection is 
>> either not  happening, or running on a different thread, or 
>> being interrupted,  or simply works differently.  I have no 
>> idea, hence asking you :) 
> 
> That is very strange.  There's only one function to perform GC, 
> and it is called both from garbage-collect and from an internal 
> function called when Emacs is idle or when it calls interpreter 
> functions like 'eval' or 'funcall'.  The only thing 
> garbage-collect does that the internal function doesn't is 
> generate the list that is the return value of garbage-collect, 
> but that cannot possibly take minutes. 
> 
> I suggest to set garbage-collection-messages non-nil, then you 
> should see when each GC, whether the one you invoke 
> interactively or the automatic one, starts and ends.  maybe the 
> minutes you wait are not directly related to GC, but to 
> something else that is triggered by GC? 

I just set garbage-collection-messages to non-nil and evaluated 
(garbage-collect), and nothing was printed... you are suggesting 
that it should print something to *Messages*, right?

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

-Trevor

Previous Next

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