From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Madhu Newsgroups: gmane.emacs.bugs Subject: bug#49656: more data on #43389 Date: Wed, 21 Jul 2021 07:16:23 +0530 (IST) Message-ID: <20210721.071623.1810463348128672347.enometh@meer.net> References: <83o8ax5hxp.fsf@gnu.org> <20210720.213837.660237047276474473.enometh@meer.net> <837dhk6hby.fsf@gnu.org> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33141"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 49656@debbugs.gnu.org To: eliz@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 21 03:47:13 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 1m61KL-0008Rj-2F for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 21 Jul 2021 03:47:13 +0200 Original-Received: from localhost ([::1]:34090 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m61KJ-0000mV-Of for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 20 Jul 2021 21:47:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37612) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m61KA-0000mL-Mu for bug-gnu-emacs@gnu.org; Tue, 20 Jul 2021 21:47:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52497) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m61KA-0003Vs-FL for bug-gnu-emacs@gnu.org; Tue, 20 Jul 2021 21:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m61KA-0001Cj-Eo for bug-gnu-emacs@gnu.org; Tue, 20 Jul 2021 21:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Madhu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 Jul 2021 01:47: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.16268319924594 (code B ref 49656); Wed, 21 Jul 2021 01:47:02 +0000 Original-Received: (at 49656) by debbugs.gnu.org; 21 Jul 2021 01:46:32 +0000 Original-Received: from localhost ([127.0.0.1]:35810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m61Jg-0001C1-14 for submit@debbugs.gnu.org; Tue, 20 Jul 2021 21:46:32 -0400 Original-Received: from smtp6.ctinetworks.com ([205.166.61.199]:52838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m61Je-0001Bt-I1 for 49656@debbugs.gnu.org; Tue, 20 Jul 2021 21:46:30 -0400 Original-Received: from localhost (unknown [117.193.14.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: enometh@meer.net) by smtp6.ctinetworks.com (Postfix) with ESMTPSA id 297AA8437C; Tue, 20 Jul 2021 21:46:25 -0400 (EDT) In-Reply-To: <837dhk6hby.fsf@gnu.org> X-Mailer: Mew version 6.8 on Emacs 28.0.50 X-ctinetworks-Information: Please contact the ISP for more information X-ctinetworks-MailScanner-ID: 297AA8437C.A97A9 X-ctinetworks-VirusCheck: Found to be clean X-ctinetworks-Watermark: 1627695989.78771@V1HIfygic/82UQkRFPL3DQ 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:210395 Archived-At: * Eli Zaretskii <837dhk6hby.fsf@gnu.org> Wrote on Tue, 20 Jul 2021 20:11:29 +0300 >> Date: Tue, 20 Jul 2021 21:38:37 +0530 (IST) >> 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? No I haven't gotten around to trying that i'm sure none of my packages mess with gc-threshold. I will double check that. > 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? The problem is not that emacs won't run. I am unable to use the memory in the machine for other purposes and am obliged to kill emacs. > Btw, 1.5GB is not too large for several days worth of work. I also have emacs running for several weeks when the problem doesn't happen with RES never above say 500M for the same workloads and usage patterns. > Are you sure no package you use does something like that? What were > the values of GC thresholds when the memory was large? Yes I do not run a lot of packages and certainly nothing that I don't audit first - I am aware of all the packages that are loaded at least in the exceptional cases. There is no reason for me to suspect those packages because I use them all the time in emacs sessions where the problem does not manifest. > 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.) There is nothing exceptional with GC. GC usually completes quickly because it doesnt access much memory. >> 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. But that is the point - I've been asking from the first time I posted on this - WHAT is emacs allocating in these exceptional cases. I understand my usage patterns over the years of constant emacs use and the "random" memory bloat in some sessions makes no sense and it only suggests a memory leak in emacs code. >> 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. This is too vague. This 2GB active memory is not legitimate and the point is to figure out where and why emacs is holding on to this memory. This is where I need assistance. my usage patterns are pretty deterministic The memory usage of the qlisp packages I use would show up in GC. SO what could that be, which it is NOT allocating under identical usage patterns? It isn't fonts or external images or anything else I can see. I'm sure others should be hitting the problem too