bug#43389: 28.0.50; Emacs memory leaks using hard disk all time

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 27 Nov 2020 10:20:46 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: fweimer@redhat.com, 43389@debbugs.gnu.org, bugs@gnu.support, dj@redhat.com,
>  michael_heerdegen@web.de, trevor@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 *).