bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Tue, 24 Nov 2020 21:35:03 +0200

> From: Trevor Bentley <trevor@trevorbentley.com>
> Cc: bugs@gnu.support, fweimer@redhat.com, 43389@debbugs.gnu.org,
>  dj@redhat.com, michael_heerdegen@web.de, carlos@redhat.com
> Cc: 
> Date: Tue, 24 Nov 2020 20:05:15 +0100
> 
> I just updated the log on my website.  Same instance a day later, 
> after yet another memory spike up to 4.3GB.  Concatenated to the 
> end:
> 
> https://trevorbentley.com/emacs_malloc_info.log

I don't think I can interpret that.  In particular, how come "total"
is 4GB, but I see no comparable sizes in any of the other fields?
where do those 4GB hide?  Carlos, can you help interpreting this
report?

> Some interesting observations:
>  - (garbage-collect) takes forever, like on the order of 5-10 
>  minutes, with one CPU core pegged to 100% and emacs frozen.

Is this with the default values of gc-cons-threshold and
gc-cons-percentage?

>  - The leaking stops for a while after (garbage-collect).  It was 
>  leaking 1MB per second for this last log, and stopped growing 
>  after the garbage collection.

Now, what happens in that session once per second (in an otherwise
idle Emacs, I presume?) to cause such memory consumption?  Some
timers?  If you run with a breakpoint in malloc that just shows the
backtrace and continues, do you see what could consume 1MB every
second?

> Question 1: (garbage-collect) shows the memory usage *after* 
> collecting, right?

Yes.

> Is there any way to get the same info without actually reaping dead
> references?

What do you mean by "reaping dead references" here?

> It could be that there really were 4.3GB of dead references.

Not sure I understand what are you trying to establish here.

> Question 2: are the background garbage collections equivalent to 
> the (garbage-collect) function?  I certainly don't notice 5-10 
> minute long pauses during normal use, though "gcs-done" is 
> incrementing.  Does it have a different algorithm for partial 
> collection during idle, perhaps?

There's only one garbage-collect, it is called for _any_ GC.

What do you mean by "during normal use" in this sentence:

  I certainly don't notice 5-10 minute long pauses during normal use,
  though "gcs-done" is incrementing.

How is what you did here, where GC took several minutes, different
from "normal usage"?

> Question 3: I've never used the malloc_trim() function.  Could 
> that be something worth experimenting with, to see if it releases 
> any of the massive heap back to the OS?

That's for glibc guys to answer.

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]