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: Thu, 10 Dec 2020 20:45:40 +0200 Message-ID: <83zh2l33fv.fsf@gnu.org> References: <83y2j0qb2v.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> <83v9dpn9em.fsf@gnu.org> <87sg8ts766.fsf@mail.trevorbentley.com> <87pn3usr13.fsf@mail.trevorbentley.com> <87eek0rmqa.fsf@mail.trevorbentley.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13201"; 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 Bentley , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 10 19:47:22 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 1knQyH-0003GY-Ry for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Dec 2020 19:47:21 +0100 Original-Received: from localhost ([::1]:49194 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knQyG-0000zq-Ud for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Dec 2020 13:47:20 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43010) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knQy1-0000zK-EZ for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 13:47:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55958) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1knQxy-0005vO-Ea for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 13:47:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1knQxy-00040s-BD for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 13:47:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Dec 2020 18:47:02 +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.160762597615371 (code B ref 43389); Thu, 10 Dec 2020 18:47:02 +0000 Original-Received: (at 43389) by debbugs.gnu.org; 10 Dec 2020 18:46:16 +0000 Original-Received: from localhost ([127.0.0.1]:39271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knQxE-0003zr-1d for submit@debbugs.gnu.org; Thu, 10 Dec 2020 13:46:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49694) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knQx9-0003za-Fq for 43389@debbugs.gnu.org; Thu, 10 Dec 2020 13:46:14 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45696) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knQx3-0005fb-DK; Thu, 10 Dec 2020 13:46:05 -0500 Original-Received: from [176.228.60.248] (port=3566 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1knQx1-0002T4-H4; Thu, 10 Dec 2020 13:46:05 -0500 In-Reply-To: <87eek0rmqa.fsf@mail.trevorbentley.com> (message from Trevor Bentley on Tue, 08 Dec 2020 22:50:37 +0100) 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:195683 Archived-At: Stefan, please help with this complex issue (or maybe several issues). We have collected some evidence in this bug report, but I don't yet see where is this going, or how to make any real progress here. One thing that I cannot explain is this: > From: Trevor Bentley > Cc: fweimer@redhat.com, 43389@debbugs.gnu.org, bugs@gnu.support, > dj@redhat.com, michael_heerdegen@web.de > Cc: > Date: Tue, 08 Dec 2020 22:50:37 +0100 > > I've been too busy to modify emacs to print garbage collects, but > these still show really long (garbage-collect) calls, often > exceeding 15 minutes. Trevor reported several times that automatic GC is fast as usual, but manual invocations of "M-x garbage-collect" take much longer, many minutes. I don't understand how this could happen, because both methods of invoking GC do exactly the same job. I thought about possible ways of explaining the stark differences in the time it takes to GC, and came up with these: . The depth of the run-time (C-level) stack. If this is much deeper in one of the cases, it could explain the longer time. But in that case, I'd expect the automatic GC to take longer, because typically the C stack is relatively shallow when Emacs is idle than when it runs some Lisp. This contradicts Trevor's observations. . Some difference in buffers and strings, which causes the manual GC to relocate and compact a lot of them. But again: (a) why the automatic GC never hits the same condition, and (b) I can explain the reverse easier, i.e. that lots of temporary strings and buffers exist while Lisp runs, but not when Emacs is idle. Any other ideas? Any data Trevor could provide, e.g. by attaching a debugger during these prolonged GC, and telling us something interesting? TIA