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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
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, Trevor Bentley <trevor <at> trevorbentley.com>, michael_heerdegen <at> web.de
Subject: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Thu, 10 Dec 2020 14:21:16 -0500

> Trevor reported several times that automatic GC is fast as usual, but
> manual invocations of "M-x garbage-collect" take much longer, many
> minutes.  I don't understand how this could happen, because both
> methods of invoking GC do exactly the same job.

Indeed, that makes no sense.  The only thing that comes to mind is that
when they do `M-x garbage-collect` the 15 minutes aren't actually spent
in the GC but in some pre/post command hook or something like that
(e.g. in `execute-extended-command--shorter`)?

Do we have a `profiler-report` available for those 15 minutes?
I've taken a quick look at the massive threads in that bug report,
but haven't had the time to read in detail.  AFAICT we don't have a
profiler output for those 15minutes, so it would be good to try:

    M-x profiler-start RET RET
    M-x garbage-collect RET     ;; This should presumably take several minutes
    M-x profiler-report RET

and then shows us this report (using C-u RET on the top-level elements
to unfold them).


        Stefan

Previous Next

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