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

[Trevor Bentley]

Eli Zaretskii <eliz@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