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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: carlos <at> redhat.com
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
Subject: Re: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Sat, 28 Nov 2020 11:00:17 +0200

> Date: Fri, 27 Nov 2020 10:20:46 +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
> 
> > > > 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.
> 
> Double oops: the above just shows that each time we process timers, we
> copy the list of the timers first.  Not sure what to do about that.
> Hmm...  Maybe we should try GC at the end of each timer_check call?

This doesn't seem to be necessary: timer functions are called via
'funcall', whose implementation already includes a call to maybe_gc.

Just to see if we have some problem there, I left an otherwise idle
Emacs with 20 timer functions firing every second run overnight.  It
gained less than 1MB of memory footprint after 10 hours.  So timers
alone cannot explain the dramatic increase in memory footprints
described in this bug report, although they might be a contributing
factor when the Emacs process already has lots of memory allocated to
it.

> Each call to lisp_align_malloc above requests a 1008-byte chunk of
> memory for a new block of Lisp conses.

More accurately, malloc is asked to provide a block of memory whose
size is 1024 bytes minus sizeof (void *).

Previous Next

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