[Top][All Lists]

[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: Trevor Bentley
Subject: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Tue, 24 Nov 2020 20:05:15 +0100

Eli Zaretskii <eliz@gnu.org> writes:

Look at the large chunks in the tail of this. Together, they do account for ~2GB. Carlos, are these chunks in use (i.e. allocated and not freed), or are they the free chunks that are available for allocation, but not released to the OS? If the former, then it sounds like this session does have around 2GB of allocated heap data, so either there's some allocated memory we don't account for, or there is indeed a memory leak in Emacs. If these are the free chunks, then the way glibc manages free'd memory is indeed an issue.

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:


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. - 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.

Question 1: (garbage-collect) shows the memory usage *after* collecting, right? Is there any way to get the same info without actually reaping dead references? It could be that there really were 4.3GB of dead references.

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?

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?


reply via email to

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