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 Date: Fri, 18 Sep 2020 09:56:14 +0300 Message-ID: <83d02j60a9.fsf@gnu.org> References: <87r1r5428d.fsf@web.de> <87mu1sry72.fsf@mail.linkov.net> <875z8fc224.fsf@web.de> <20200915175418.GV20869@maokai> <838sda98jm.fsf@gnu.org> <20200915211209.GW20869@maokai> <83pn6l7ozj.fsf@gnu.org> <20200917204704.GA20217@maokai> <87ft7gjc9w.fsf@dismail.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39493"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43389@debbugs.gnu.org To: Joshua Branson Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 18 08:57:10 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 1kJAKU-000A9f-B3 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 18 Sep 2020 08:57:10 +0200 Original-Received: from localhost ([::1]:39838 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJAKR-00040z-OF for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 18 Sep 2020 02:57:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56454) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJAKM-00040r-9Y for bug-gnu-emacs@gnu.org; Fri, 18 Sep 2020 02:57:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57189) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kJAKM-0008KL-0V for bug-gnu-emacs@gnu.org; Fri, 18 Sep 2020 02:57:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kJAKL-0004vS-WF for bug-gnu-emacs@gnu.org; Fri, 18 Sep 2020 02:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 18 Sep 2020 06:57: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.160041217218860 (code B ref 43389); Fri, 18 Sep 2020 06:57:01 +0000 Original-Received: (at 43389) by debbugs.gnu.org; 18 Sep 2020 06:56:12 +0000 Original-Received: from localhost ([127.0.0.1]:40502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJAJY-0004u8-17 for submit@debbugs.gnu.org; Fri, 18 Sep 2020 02:56:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJAJT-0004tq-W3 for 43389@debbugs.gnu.org; Fri, 18 Sep 2020 02:56:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57164) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJAJN-0008Gj-LI; Fri, 18 Sep 2020 02:56:01 -0400 Original-Received: from [176.228.60.248] (port=3409 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kJAJM-0000YV-S3; Fri, 18 Sep 2020 02:56:01 -0400 In-Reply-To: <87ft7gjc9w.fsf@dismail.de> (bug-gnu-emacs@gnu.org) 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:188267 Archived-At: > Date: Thu, 17 Sep 2020 17:58:51 -0400 > From: Joshua Branson via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > > Over in #guix irc, the guix people seemed to think it was a memory leak with helm. Thanks. But if it's due to helm, why doesn't the huge memory usage show in the report produced by GC? That report should show all the Lisp object that we allocate and manage, no? Where does helm-ff-cache keeps those "candidates"? (And what is this cache, if someone could be kind enough to describe it?)