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#49656: more data on #43389 Date: Tue, 20 Jul 2021 20:11:29 +0300 Message-ID: <837dhk6hby.fsf@gnu.org> References: <20210720.124331.173592885202931943.enometh@meer.net> <83o8ax5hxp.fsf@gnu.org> <20210720.213837.660237047276474473.enometh@meer.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20552"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 49656@debbugs.gnu.org To: Madhu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 20 19:12:10 2021 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 1m5tHt-00057Q-LS for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 20 Jul 2021 19:12:09 +0200 Original-Received: from localhost ([::1]:40278 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5tHs-0000lE-N5 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 20 Jul 2021 13:12:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51076) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5tHm-0000kr-KX for bug-gnu-emacs@gnu.org; Tue, 20 Jul 2021 13:12:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51922) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m5tHm-00078o-D2 for bug-gnu-emacs@gnu.org; Tue, 20 Jul 2021 13:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m5tHm-0003NS-6I for bug-gnu-emacs@gnu.org; Tue, 20 Jul 2021 13:12: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: Tue, 20 Jul 2021 17:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49656 X-GNU-PR-Package: emacs Original-Received: via spool by 49656-submit@debbugs.gnu.org id=B49656.162680110312958 (code B ref 49656); Tue, 20 Jul 2021 17:12:02 +0000 Original-Received: (at 49656) by debbugs.gnu.org; 20 Jul 2021 17:11:43 +0000 Original-Received: from localhost ([127.0.0.1]:35235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5tHS-0003Mv-PH for submit@debbugs.gnu.org; Tue, 20 Jul 2021 13:11:43 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53218) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5tHQ-0003Mi-Dg for 49656@debbugs.gnu.org; Tue, 20 Jul 2021 13:11:41 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52114) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5tHK-0006jR-SN; Tue, 20 Jul 2021 13:11:34 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3736 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5tHK-0004PT-Ft; Tue, 20 Jul 2021 13:11:34 -0400 In-Reply-To: <20210720.213837.660237047276474473.enometh@meer.net> (message from Madhu on Tue, 20 Jul 2021 21:38:37 +0530 (IST)) 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:210382 Archived-At: > Date: Tue, 20 Jul 2021 21:38:37 +0530 (IST) > Cc: 49656@debbugs.gnu.org > From: Madhu > > In all other cases I hit the memory leak gc thinks it only has 200M > while the process has 1.5 to 3.5 GB resident. > > I don't see how this can be a user error. It could be if, for example, you are using packages or your own code which plays with GC thresholds. E.g., I'm told that lsp-mode does that; are you per chance using it? > > So what we need is the following, for each case separately: > > . the size of the memory footprint of the Emacs session > > I have this data for a few runs. The sizes from `ps' correspond > exactly to what malloc info shows so i decided to omit it. Ah, but gleaning this from the malloc info takes some time, so telling the number explicitly will help making the report more easily understandable. > > . how long was the Emacs session running since it started > > 2-3 days usually. I always have to kill emacs because I cant suspend > the OS to disk because all of it is resident. How much memory and swap do you have there? Can you enlarge the total VM size (by enlarging swap) so that you could run Emacs longer when it gets to such large sizes? Btw, 1.5GB is not too large for several days worth of work. > > . what were the main activities in that session . do you have some > > customizations related to GC, and if you do, what are they . what > > Emacs version is that, and what are its configuration parameters > > and features compiled into it > > I am not doing anything special with GC. Are you sure no package you use does something like that? What were the values of GC thresholds when the memory was large? Was the value of gcs-done increasing with time, or did it stay put (which would be an evidence that Emacs doesn't run GC at all)? If GC was running, how frequently did it run? (You could answer the last question either by looking at the rate of growth in gcs-done, or by setting garbage-collection-messages non-nil, which will cause Emacs announce ever GC in the echo area.) > if you remember I asked on emacs-help once and you informed me of a GC > fix and it fixed that problem. But that problem was fixed, so it cannot possibly affect you now. And we found that problem because the user reported lack of GC cycles after some point. > But doesn't the malloc info allocation and the gc reports indicate a > clear discrepancy? Not to me, it doesn't. It means the malloc arena holds to a lot of memory that it cannot release to the OS, but it is known that this can happen for certain patterns of memory allocation and deallocation. You can find explanations of why this happens on the net. > Does it not indicate a leak which the GC is not aware of? No. Emacs allocates a lot of memory for purposes other than Lisp objects, and that memory is not visible to GC nor to memory-report.