GNU bug report logs - #43389
28.0.50; Emacs memory leaks

Previous Next

Full log

View this message in rfc822 format

From: Trevor Bentley <trevor <at> trevorbentley.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, bugs <at> gnu.support, dj <at> redhat.com, carlos <at> redhat.com, michael_heerdegen <at> web.de, 
Subject: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Thu, 26 Nov 2020 16:19:53 +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. 

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.