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

Previous Next

Full log

Message #593 received at 43389 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: trevor <at> trevorbentley.com
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: Re: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Fri, 27 Nov 2020 09:52:00 +0200

> Date: Fri, 27 Nov 2020 09:40:53 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, bugs <at> gnu.support, dj <at> redhat.com,
>  michael_heerdegen <at> web.de, trevor <at> trevorbentley.com
> 
> > Cc: trevor <at> trevorbentley.com, bugs <at> gnu.support, fweimer <at> redhat.com,
> >  43389 <at> debbugs.gnu.org, dj <at> redhat.com, michael_heerdegen <at> web.de
> > From: Carlos O'Donell <carlos <at> redhat.com>
> > Date: Fri, 27 Nov 2020 00:04:56 -0500
> > 
> > >> 448.2 MiB: Fmake_list
> > >> 270.3 MiB: in 262 places all over the place (below massif's threshold)
> > >> 704.0 MiB: list4 -> exec_byte_code
> > >> 109.7 MiB: F*_json_read_string_0 -> funcall_subr ...
> > >> 102.2 MiB: Flist -> exec_byte_code ...
> > >>  68.5 MiB: Fcopy_alist -> Fframe_parameters ...
> > > 
> > > Thanks.  Those are the low-level primitives, they tell nothing about
> > > the Lisp code which caused this much memory allocation.  We need
> > > higher levels of callstack, and preferably in Lisp terms.  GDB
> > > backtraces would show them, due to tailoring in src/.gdbinit.
> > 
> > Sure, let me pick one for you:
> > 
> > lisp_align_malloc (alloc.c:1195)
> >  Fcons (alloc.c:2694)
> >   concat (fns.c:730)
> >    Fcopy_sequence (fns.c:598)
> >     timer_check (keyboard.c:4395)
> >      wait_reading_process_output (process.c:5334)
> >       sit_for (dispnew.c:6056)
> >        read_char (keyboard.c:2742)
> >         read_key_sequence (keyboard.c:9551)
> >          command_loop_1 (keyboard.c:1354)
> >           internal_condition_case (eval.c:1365)
> >            command_loop_2 (keyboard.c:1095)
> >             internal_catch (eval.c:1126)
> >              command_loop (keyboard.c:1074)
> >               recursive_edit_1 (keyboard.c:718)
> >                Frecursive_edit (keyboard.c:790)
> >                 main (emacs.c:2080)
> >  
> > There is a 171MiB's worth of allocations in that path.
> > 
> > There are a lot of traces ending in wait_reading_process_output that
> > are consuming 50MiB.
> 
> Thanks.  If they are like the one above, the allocations are due to
> some timer.  Could be jabber, I'll take a look at it.  Or maybe
> helm-ff--cache-mode-refresh, whatever that is; need to look at Helm as
> well.

Oops, I got this mixed up: the timer list is from Jean, but the massif
files are from Trevor.

Trevor, can you show the list of timers running on your system?

Previous Next

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