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: Tue, 17 Nov 2020 22:27:27 +0200 Message-ID: <83ft57raog.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28286"; mail-complaints-to="usenet@ciao.gmane.io" Cc: fweimer@redhat.com, carlos@redhat.com, 43389@debbugs.gnu.org To: DJ Delorie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 17 21:28: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 1kf7aE-0007Fs-EM for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 17 Nov 2020 21:28:10 +0100 Original-Received: from localhost ([::1]:60854 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kf7aD-0004ZW-HK for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 17 Nov 2020 15:28:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49576) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kf7a6-0004ZK-FO for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2020 15:28:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49739) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kf7a6-0000lY-37 for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2020 15:28:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kf7a5-0005MP-UX for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2020 15:28: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: Tue, 17 Nov 2020 20:28: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.160564486020570 (code B ref 43389); Tue, 17 Nov 2020 20:28:01 +0000 Original-Received: (at 43389) by debbugs.gnu.org; 17 Nov 2020 20:27:40 +0000 Original-Received: from localhost ([127.0.0.1]:33051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kf7Zk-0005Li-2K for submit@debbugs.gnu.org; Tue, 17 Nov 2020 15:27:40 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49410) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kf7Zi-0005LV-Tx for 43389@debbugs.gnu.org; Tue, 17 Nov 2020 15:27:39 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33989) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kf7Zd-0000cT-JE; Tue, 17 Nov 2020 15:27:33 -0500 Original-Received: from [176.228.60.248] (port=3250 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kf7Zc-0001FY-FJ; Tue, 17 Nov 2020 15:27:33 -0500 In-Reply-To: (message from DJ Delorie on Tue, 17 Nov 2020 15:16:11 -0500) 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:193577 Archived-At: > From: DJ Delorie > Cc: eliz@gnu.org, carlos@redhat.com, 43389@debbugs.gnu.org > Date: Tue, 17 Nov 2020 15:16:11 -0500 > > Florian Weimer writes: > > But how helpful would that be, given that malloc_info does not really > > show any inactive memory (discounting my 200 MiB hole)? > > One doesn't know how helpful until after looking at the data. If RSS is > going up fast, something is calling either sbrk or mmap. If that thing > is malloc, a trace tells us if there's a pattern. If that pattern > blames the lisp allocator, my job here is done ;-) I won't hold my breath for the lisp allocator to take the blame. A couple of people who were hit by the problem reported the statistics of Lisp objects as produced by GC (those reports are somewhere in the bug discussions, you should be able to find them). Those statistics indicated a very moderate amount of live Lisp objects, nowhere near the huge memory footprint. (It would be interesting to see the GC statistics from Florian's session, btw.) Given this data, it seems that if the Lisp allocator is involved, the real problem is in what happens with memory it frees when objects are GC'ed.