From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time Date: Sat, 28 Nov 2020 11:00:17 +0200 Message-ID: <83v9dpn9em.fsf@gnu.org> References: <83y2j0qb2v.fsf@gnu.org> <831rgppg3w.fsf@gnu.org> <83zh3czbvz.fsf@gnu.org> <83blfovzxz.fsf@gnu.org> <87o8jnu5f2.fsf@mail.trevorbentley.com> <83o8jmu49z.fsf@gnu.org> <522e3cc0-c563-3308-7264-1b09cd5e264b@redhat.com> <87o8jltglg.fsf@mail.trevorbentley.com> <43b8f55b-d201-76e0-2d19-d97dec8798aa@redhat.com> <87im9ttfeg.fsf@mail.trevorbentley.com> <399d4681-940a-c782-b91e-750e62840cb6@redhat.com> <83pn40qkyb.fsf@gnu.org> <418751f6-41be-a5e2-908a-ea4196d5fb9b@redhat.com> <83y2inq2sp.fsf@gnu.org> <60253612-49f0-a1aa-b9e6-39cfef8d62b5@redhat.com> <83mtz3p7qy.fsf@gnu.org> <83lfenp78f.fsf@gnu.org> <83h7pbp5wh.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39010"; mail-complaints-to="usenet@ciao.gmane.io" Cc: fweimer@redhat.com, 43389@debbugs.gnu.org, bugs@gnu.support, dj@redhat.com, michael_heerdegen@web.de, trevor@trevorbentley.com To: carlos@redhat.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 28 10:01:25 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kiw6f-000A3z-9n for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 28 Nov 2020 10:01:25 +0100 Original-Received: from localhost ([::1]:38150 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kiw6d-0002ik-TF for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 28 Nov 2020 04:01:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51326) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kiw6I-0002iR-1T for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2020 04:01:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35386) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kiw6H-0000pl-Pw for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2020 04:01:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kiw6H-0004nz-NC for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2020 04:01:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Nov 2020 09:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43389 X-GNU-PR-Package: emacs Original-Received: via spool by 43389-submit@debbugs.gnu.org id=B43389.160655404718445 (code B ref 43389); Sat, 28 Nov 2020 09:01:01 +0000 Original-Received: (at 43389) by debbugs.gnu.org; 28 Nov 2020 09:00:47 +0000 Original-Received: from localhost ([127.0.0.1]:46932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kiw63-0004nQ-B5 for submit@debbugs.gnu.org; Sat, 28 Nov 2020 04:00:47 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33046) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kiw60-0004nC-Nh for 43389@debbugs.gnu.org; Sat, 28 Nov 2020 04:00:45 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42134) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kiw5u-0000jS-R3; Sat, 28 Nov 2020 04:00:38 -0500 Original-Received: from [176.228.60.248] (port=2186 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kiw5p-00054N-DA; Sat, 28 Nov 2020 04:00:38 -0500 In-Reply-To: <83h7pbp5wh.fsf@gnu.org> (message from Eli Zaretskii on Fri, 27 Nov 2020 10:20:46 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:194482 Archived-At: > Date: Fri, 27 Nov 2020 10:20:46 +0200 > From: Eli Zaretskii > 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 *).