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

[Trevor Bentley]

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

Oh, it may be subprocesses instead of threads.  emacs-slack is 
doing all sorts of things, involving both ImageMagick and 
launching curl subprocesses.  Is there a way to prevent libmtrace 
from following children?

I've just hooked make-process and make-thread, and see both being 
called back-to-back very often for spawning curl subprocesses.

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

Gotcha.  No surprise, then.

-Trevor