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

[Eli Zaretskii]

> From: Trevor Bentley <trevor@trevorbentley.com>
> Cc: bugs@gnu.support, fweimer@redhat.com, 43389@debbugs.gnu.org,
>  dj@redhat.com, michael_heerdegen@web.de
> Cc: 
> Date: Thu, 26 Nov 2020 13:37:54 +0100
> 
> If it's one trace per thread, though, then we at least know that 
> my emacs process in question is blazing through threads.

I don't see how this could be true, unless some library you use
(ImageMagick?) starts a lot of threads.  Emacs itself is
single-threaded, and the only other threads are those from GTK, which
should be very few (like, 4 or 5).  This assumes you didn't use Lisp
threads, of course.

> Other thing to note (for Eli): I wrapped garbage-collect like so:
> 
> ---
> (defun trev/garbage-collect (orig-fun &rest args) 
>   (message "%s -- Starting garbage-collect." 
>   (current-time-string)) (let ((time (current-time)) 
>         (result (apply orig-fun args))) 
>     (message "%s -- Finished garbage-collect in %.06f" 
>     (current-time-string) (float-time (time-since time))) result)) 
> (add-function :around (symbol-function 'garbage-collect) 
> #'trev/garbage-collect)
> ---
> 
> This printed a start and stop message each time I evaluated 
> garbage-collect manually.  It did not print any messages in 11 
> hours of running unattended.

That's expected, because the automatic GC doesn't call
garbage-collect.  garbage-collect is just a thin wrapper around a C
function, called garbage_collect, and the automatic GC calls that
function directly from C.  And you cannot advise C functions not
exposed to Lisp.

If you want to have record of the times it took each GC to run, you
will have to modify the C sources.