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>
> Cc: bugs <at> gnu.support, fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org,
> dj <at> redhat.com, michael_heerdegen <at> 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.
This bug report was last modified 4 years and 58 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.