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: Fri, 27 Nov 2020 09:52:00 +0200 Message-ID: <83lfenp78f.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24934"; mail-complaints-to="usenet@ciao.gmane.io" Cc: fweimer@redhat.com, 43389@debbugs.gnu.org, bugs@gnu.support, dj@redhat.com, carlos@redhat.com, michael_heerdegen@web.de To: trevor@trevorbentley.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 27 08:53:09 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 1kiYZ3-0006Ny-P5 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 27 Nov 2020 08:53:09 +0100 Original-Received: from localhost ([::1]:54472 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kiYZ2-0001DM-O8 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 27 Nov 2020 02:53:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38826) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kiYYv-0001D2-V8 for bug-gnu-emacs@gnu.org; Fri, 27 Nov 2020 02:53:01 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60410) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kiYYv-0003dI-Nb for bug-gnu-emacs@gnu.org; Fri, 27 Nov 2020 02:53:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kiYYv-00018k-L9 for bug-gnu-emacs@gnu.org; Fri, 27 Nov 2020 02:53: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: Fri, 27 Nov 2020 07:53: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.16064635484341 (code B ref 43389); Fri, 27 Nov 2020 07:53:01 +0000 Original-Received: (at 43389) by debbugs.gnu.org; 27 Nov 2020 07:52:28 +0000 Original-Received: from localhost ([127.0.0.1]:43723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kiYYO-00017x-BL for submit@debbugs.gnu.org; Fri, 27 Nov 2020 02:52:28 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:48732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kiYYM-00017l-MU for 43389@debbugs.gnu.org; Fri, 27 Nov 2020 02:52:27 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60885) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kiYYF-0003Ov-Lh; Fri, 27 Nov 2020 02:52:20 -0500 Original-Received: from [176.228.60.248] (port=4768 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kiYYD-0004qN-J2; Fri, 27 Nov 2020 02:52:18 -0500 In-Reply-To: <83mtz3p7qy.fsf@gnu.org> (message from Eli Zaretskii on Fri, 27 Nov 2020 09:40:53 +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:194402 Archived-At: > Date: Fri, 27 Nov 2020 09:40:53 +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 > > > Cc: trevor@trevorbentley.com, bugs@gnu.support, fweimer@redhat.com, > > 43389@debbugs.gnu.org, dj@redhat.com, michael_heerdegen@web.de > > From: Carlos O'Donell > > 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?