GNU bug report logs - #49656
Abnormal Emacs memory usage (bug#43389)

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Madhu <enometh@HIDDEN>; dated Tue, 20 Jul 2021 07:21:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 49656 <at> debbugs.gnu.org:


Received: (at 49656) by debbugs.gnu.org; 21 Jul 2021 12:21:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 21 08:21:50 2021
Received: from localhost ([127.0.0.1]:36380 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m6BEU-0004sO-5r
	for submit <at> debbugs.gnu.org; Wed, 21 Jul 2021 08:21:50 -0400
Received: from eggs.gnu.org ([209.51.188.92]:48624)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1m6BES-0004sA-5n
 for 49656 <at> debbugs.gnu.org; Wed, 21 Jul 2021 08:21:48 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:46014)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1m6BEM-0004R0-Dj; Wed, 21 Jul 2021 08:21:42 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2273
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1m6BEM-00087z-1q; Wed, 21 Jul 2021 08:21:42 -0400
Date: Wed, 21 Jul 2021 15:21:40 +0300
Message-Id: <83y29z502z.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Madhu <enometh@HIDDEN>
In-Reply-To: <20210721.071623.1810463348128672347.enometh@HIDDEN> (message
 from Madhu on Wed, 21 Jul 2021 07:16:23 +0530 (IST))
Subject: Re: bug#49656: more data on #43389
References: <83o8ax5hxp.fsf@HIDDEN>
 <20210720.213837.660237047276474473.enometh@HIDDEN>
 <837dhk6hby.fsf@HIDDEN>
 <20210721.071623.1810463348128672347.enometh@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 49656
Cc: 49656 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Wed, 21 Jul 2021 07:16:23 +0530 (IST)
> Cc: 49656 <at> debbugs.gnu.org
> From: Madhu <enometh@HIDDEN>
> 
> > 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.

Thanks, please do.  It's important to know 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.

If you enlarge the swap space, your system will still be workable even
when Emacs has such a large footprint.  That's the purpose of my
suggestion.  It is important to have a usable system when these
situations happen because if we come up with some experiments to
conduct in such cases, you need a usable system to be able to do that.

> > 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.

Then one thing to try to figure out is what was the difference between
these two classes of sessions -- what and how did you do differently
in one that you didn't in the other?  That could point us in the right
direction.

> >  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.

I'd like quantitative measures, please: what is the rate of GC cycles
when the memory footprint is measurd in GBs, and how much time does
each GC cycle take?  Also, does the memory footprint becomes smaller
after a GC cycle, and by how much?

> >> 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.

It's impractical to try to answer these questions.  If you put a
breakpoint on 'malloc' and 'free' and then run Emacs, you will see
that it calls these functions extremely frequently, with widely
different block sizes.  We don't have infrastructure that would record
each allocation and deallocation with enough info to be able to
analyze that, and even if we did, finding the callers which are
responsible for the memory that's not returned to the OS is a very
large and hard job.  We tried that previously, with the help of the
glibc developers using their debugging features -- it didn't really
help us with the diagnostics.

> 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.

It is impossible to look for memory leaks in Emacs without some clues
about where those leaks could be.  If you can provide the information
I asked above, we might be able to come up with such clues.

Alternatively, you could try running Emacs under Valgrind (see
instructions in etc/DEBUG), although this will probably catch memory
leaks only on the C level, not on the Lisp level.

> >> 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.

But that's all I can say, given the information you provided till now.

> 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.

This is me assisting you.  I'm asking you to help us analyze this
problem by providing more information.  I don't think we will be able
to make progress here without that additional info.

> SO what could that be, which it is NOT allocating under identical
> usage patterns?

I don't know, sorry.

> I'm sure others should be hitting the problem too

We could, of course, wait for others to report similar problems, and
then hope the information they provide would point us to the right
direction.  IME, though, this is not a very efficient method, because
in many cases the reasons for the memory growth are not the same.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#49656; Package emacs. Full text available.
Changed bug title to 'Abnormal Emacs memory usage (bug#43389)' from 'more data on #43389' Request was from Lars Ingebrigtsen <larsi@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 49656 <at> debbugs.gnu.org:


Received: (at 49656) by debbugs.gnu.org; 21 Jul 2021 01:46:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 20 21:46:32 2021
Received: from localhost ([127.0.0.1]:35810 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m61Jg-0001C1-14
	for submit <at> debbugs.gnu.org; Tue, 20 Jul 2021 21:46:32 -0400
Received: from smtp6.ctinetworks.com ([205.166.61.199]:52838)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <enometh@HIDDEN>) id 1m61Je-0001Bt-I1
 for 49656 <at> debbugs.gnu.org; Tue, 20 Jul 2021 21:46:30 -0400
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@HIDDEN)
 by smtp6.ctinetworks.com (Postfix) with ESMTPSA id 297AA8437C;
 Tue, 20 Jul 2021 21:46:25 -0400 (EDT)
Date: Wed, 21 Jul 2021 07:16:23 +0530 (IST)
Message-Id: <20210721.071623.1810463348128672347.enometh@HIDDEN>
To: eliz@HIDDEN
Subject: Re: bug#49656: more data on #43389
From: Madhu <enometh@HIDDEN>
In-Reply-To: <837dhk6hby.fsf@HIDDEN>
References: <83o8ax5hxp.fsf@HIDDEN>
 <20210720.213837.660237047276474473.enometh@HIDDEN>
 <837dhk6hby.fsf@HIDDEN>
X-Mailer: Mew version 6.8 on Emacs 28.0.50
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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-SpamCheck: 
X-ctinetworks-Watermark: 1627695989.78771@V1HIfygic/82UQkRFPL3DQ
X-Spam-Score: 1.5 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: * Eli Zaretskii <eliz@HIDDEN> <837dhk6hby.fsf@HIDDEN> Wrote
 on Tue, 20 Jul 2021 20:11:29 +0300 >> Date: Tue, 20 Jul 2021 21:38:37 +0530
 (IST) >> From: Madhu <enometh@HIDDEN> >> >> In all other cas [...] 
 Content analysis details:   (1.5 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 1.5 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
 [117.193.14.230 listed in dnsbl.sorbs.net]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
X-Debbugs-Envelope-To: 49656
Cc: 49656 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)

*  Eli Zaretskii <eliz@HIDDEN> <837dhk6hby.fsf@HIDDEN>
Wrote on Tue, 20 Jul 2021 20:11:29 +0300
>> Date: Tue, 20 Jul 2021 21:38:37 +0530 (IST)
>> From: Madhu <enometh@HIDDEN>
>>
>> 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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#49656; Package emacs. Full text available.

Message received at 49656 <at> debbugs.gnu.org:


Received: (at 49656) by debbugs.gnu.org; 20 Jul 2021 17:11:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 20 13:11:43 2021
Received: from localhost ([127.0.0.1]:35235 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m5tHS-0003Mv-PH
	for submit <at> debbugs.gnu.org; Tue, 20 Jul 2021 13:11:43 -0400
Received: from eggs.gnu.org ([209.51.188.92]:53218)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1m5tHQ-0003Mi-Dg
 for 49656 <at> debbugs.gnu.org; Tue, 20 Jul 2021 13:11:41 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:52114)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1m5tHK-0006jR-SN; Tue, 20 Jul 2021 13:11:34 -0400
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 <eliz@HIDDEN>)
 id 1m5tHK-0004PT-Ft; Tue, 20 Jul 2021 13:11:34 -0400
Date: Tue, 20 Jul 2021 20:11:29 +0300
Message-Id: <837dhk6hby.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Madhu <enometh@HIDDEN>
In-Reply-To: <20210720.213837.660237047276474473.enometh@HIDDEN> (message
 from Madhu on Tue, 20 Jul 2021 21:38:37 +0530 (IST))
Subject: Re: bug#49656: more data on #43389
References: <20210720.124331.173592885202931943.enometh@HIDDEN>
 <83o8ax5hxp.fsf@HIDDEN> <20210720.213837.660237047276474473.enometh@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 49656
Cc: 49656 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Tue, 20 Jul 2021 21:38:37 +0530 (IST)
> Cc: 49656 <at> debbugs.gnu.org
> From: Madhu <enometh@HIDDEN>
> 
> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#49656; Package emacs. Full text available.

Message received at 49656 <at> debbugs.gnu.org:


Received: (at 49656) by debbugs.gnu.org; 20 Jul 2021 16:08:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 20 12:08:46 2021
Received: from localhost ([127.0.0.1]:35160 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m5sIY-0001qf-Ck
	for submit <at> debbugs.gnu.org; Tue, 20 Jul 2021 12:08:46 -0400
Received: from smtp6.ctinetworks.com ([205.166.61.199]:34882)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <enometh@HIDDEN>) id 1m5sIW-0001qW-00
 for 49656 <at> debbugs.gnu.org; Tue, 20 Jul 2021 12:08:44 -0400
Received: from localhost (unknown [117.193.15.42])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 (Authenticated sender: enometh@HIDDEN)
 by smtp6.ctinetworks.com (Postfix) with ESMTPSA id D9F1485942;
 Tue, 20 Jul 2021 12:08:39 -0400 (EDT)
Date: Tue, 20 Jul 2021 21:38:37 +0530 (IST)
Message-Id: <20210720.213837.660237047276474473.enometh@HIDDEN>
To: eliz@HIDDEN
Subject: Re: bug#49656: more data on #43389
From: Madhu <enometh@HIDDEN>
In-Reply-To: <83o8ax5hxp.fsf@HIDDEN>
References: <20210720.124331.173592885202931943.enometh@HIDDEN>
 <83o8ax5hxp.fsf@HIDDEN>
X-Mailer: Mew version 6.8 on Emacs 28.0.50
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ctinetworks-Information: Please contact the ISP for more information
X-ctinetworks-MailScanner-ID: D9F1485942.A89E1
X-ctinetworks-VirusCheck: Found to be clean
X-ctinetworks-SpamCheck: 
X-ctinetworks-Watermark: 1627661323.30683@6w+5Ep33KYPJT9Z/5YPXdQ
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 49656
Cc: 49656 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

*  Eli Zaretskii <eliz@HIDDEN> <83o8ax5hxp.fsf@HIDDEN>
Wrote on Tue, 20 Jul 2021 14:43:46 +0300

>> This is the emacs memory bloat issue. I thought I had unarchived the
>> bug earlier but it seems to be closed up again. Should I open a new
>> bug? Its already got a 1000 posts on the bugzilla page
> I'm not yet sure this is a bug, FWIW.

It's been bugging me for a few years now, but I won't mind if you
close it.

>> Over the past few months, I've experienced the memory problem a few
>> times.  I wanted to share the malloc info data I collected on 3
>> instance and am attaching a tarball with 3 directories named 4 5 6
>> which include malloc-info, memory-usage, and memory-report data from
>> emacs exhibiting the behaviour - after all buffers are killed and
>> after an M-x gc.
>> Directories 4 and 6 show the common pattern where memory is used
>> unknown to GC. data in directory 5 probably another issue where there
>> are a lot of dead strings.
> I've looked at the data, thanks.  But the most important information
> is missing from the data you presented.  The case where you have 570MB
> in strings could be interesting, but without knowing what you did in
> that session, it is impossible to say whether there's an issue there.
> It could be explained by the live Lisp data you produced in that
> session.

That 570MB case was the exceptional case - i noticed that only
once.

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.

> 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.

>   . 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.

>   . 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. All the recent reports are on
Emacs 28, within a month of two of master.  The problem is independent
of the toolkit, I get it in motif, gtk, and xt.  I havent tried a no-x
build in 2 years.

if you remember I asked on emacs-help once and you informed me of a GC
fix and it fixed that problem.

> In general, that old bug is closed, because after making a single
> change that did cause memory bloat in some usage patterns, we
> concluded that the rest were user problems caused by messing with GC
> thresholds.  The glibc developers looked at the data we collected
> and found nothing that could be interpreted as a bug in glibc.

But doesn't the malloc info allocation and the gc reports indicate a
clear discrepancy?  Does it not indicate a leak which the GC is not
aware of?





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#49656; Package emacs. Full text available.

Message received at 49656 <at> debbugs.gnu.org:


Received: (at 49656) by debbugs.gnu.org; 20 Jul 2021 11:56:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 20 07:56:29 2021
Received: from localhost ([127.0.0.1]:33063 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m5oMP-0002Ju-30
	for submit <at> debbugs.gnu.org; Tue, 20 Jul 2021 07:56:29 -0400
Received: from quimby.gnus.org ([95.216.78.240]:56536)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1m5oMM-0002Jf-Lh
 for 49656 <at> debbugs.gnu.org; Tue, 20 Jul 2021 07:56:27 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=qQ4Fnhcmmgy3lXpYEa8o06Qg2DoyE9N18+WKKPhZ38E=; b=Qm0F05jQ7qDPdGI2cAQfe5PF+q
 PyNzFMzAtMTAn42B1O3SR4HePMxExulvZhhYxxSh7WVb0MFE1lOAVjZAO7VSybz5nZKzOtgf+sV2e
 ILWBfT4rRcxzmV6rBIUlrb0ySWGe4qxbsOTilMWM7vp90z0BcObPV/xuIo7wDK/IHUyI=;
Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1m5oMD-0002nb-R6; Tue, 20 Jul 2021 13:56:20 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Madhu <enometh@HIDDEN>
Subject: Re: bug#49656: more data on #43389
References: <20210720.124331.173592885202931943.enometh@HIDDEN>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj
 SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAALVBMVEUFBAsPESopFRpd
 FB/PKzbVXp1JT0PdtUy7vMOUDhpBiiEhJFk/XKJckM/////cWtUyAAAAAWJLR0QOb70wTwAAAAd0
 SU1FB+UHFAsyK6qffpkAAAFRSURBVDjLY2CAAAEG+gEmYyVlBWwSLKEhoQ7YJFSAEk5YzElgS04z
 NoByGYGeYAKz2CrawLQgQi0jVKIMrLHcGc0otrQkMFXuiSLcXgGzaoonsjkM7eWwANNENarchQGL
 hKYlzJEMSgxKSkgeczFggASFiQtKkIAkIFZMmYmQYFJSYALqFgC7QokRoZzTBRQ8TDNBwADZHLCE
 ANMEJSVNYyQJJSUmMJcJSDApCiAkVq2C2pSAFkIEJTCS0LZEKEMBTWL3bqhRBgw4gLERugh3Nshe
 prQ0QSAQQIpYnt6LoGi5c/YMEN65i+QIQQFpaRj3zA0U1+09cQDmljM4JBjgcQ0G0jIbEOwbG5D1
 MOyIhkl0oAbOjmCYxF1UHfCwYhRCDzWYxG50CcaNG8GUIKbSjbjCkYFRgBG7BYyCikIK2CTE0tLS
 ErBJCCoJauNwLB0BAObeQfYY7VR9AAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIxLTA3LTIwVDExOjUw
 OjQzKzAwOjAwAdqZaAAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMS0wNy0yMFQxMTo1MDo0MyswMDow
 MHCHIdQAAAAASUVORK5CYII=
X-Now-Playing: Squarepusher's _Be Up A Hello_: "Nervelevers"
Date: Tue, 20 Jul 2021 13:56:17 +0200
In-Reply-To: <20210720.124331.173592885202931943.enometh@HIDDEN> (Madhu's
 message of "Tue, 20 Jul 2021 12:43:31 +0530 (IST)")
Message-ID: <87fsw9gpwe.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Madhu <enometh@HIDDEN> writes: > This is the emacs memory
 bloat issue. I thought I had unarchived the > bug earlier but it seems to
 be closed up again. Unarchiving a bug doesn't reopen it -- you have to do
 both. Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 49656
Cc: 49656 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Madhu <enometh@HIDDEN> writes:

> This is the emacs memory bloat issue. I thought I had unarchived the
> bug earlier but it seems to be closed up again.

Unarchiving a bug doesn't reopen it -- you have to do both.

> Should I open a new bug? Its already got a 1000 posts on the bugzilla
> page

You did open a new bug report.  :-)  bug#49656.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#49656; Package emacs. Full text available.

Message received at 49656 <at> debbugs.gnu.org:


Received: (at 49656) by debbugs.gnu.org; 20 Jul 2021 11:43:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 20 07:43:59 2021
Received: from localhost ([127.0.0.1]:32993 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m5oAJ-0008Cu-2t
	for submit <at> debbugs.gnu.org; Tue, 20 Jul 2021 07:43:59 -0400
Received: from eggs.gnu.org ([209.51.188.92]:38856)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1m5oAG-0008Ch-Nu
 for 49656 <at> debbugs.gnu.org; Tue, 20 Jul 2021 07:43:57 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:41002)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1m5oAB-0001Jy-5K; Tue, 20 Jul 2021 07:43:51 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3420
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1m5oAA-0002Bx-MJ; Tue, 20 Jul 2021 07:43:51 -0400
Date: Tue, 20 Jul 2021 14:43:46 +0300
Message-Id: <83o8ax5hxp.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Madhu <enometh@HIDDEN>
In-Reply-To: <20210720.124331.173592885202931943.enometh@HIDDEN> (message
 from Madhu on Tue, 20 Jul 2021 12:43:31 +0530 (IST))
Subject: Re: bug#49656: more data on #43389
References: <20210720.124331.173592885202931943.enometh@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 49656
Cc: 49656 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Tue, 20 Jul 2021 12:43:31 +0530 (IST)
> From: Madhu <enometh@HIDDEN>
> 
> This is the emacs memory bloat issue. I thought I had unarchived the
> bug earlier but it seems to be closed up again. Should I open a new
> bug? Its already got a 1000 posts on the bugzilla page

I'm not yet sure this is a bug, FWIW.

> Over the past few months, I've experienced the memory problem a few
> times.  I wanted to share the malloc info data I collected on 3
> instance and am attaching a tarball with 3 directories named 4 5 6
> which include malloc-info, memory-usage, and memory-report data from
> emacs exhibiting the behaviour - after all buffers are killed and
> after an M-x gc.
> 
> Directories 4 and 6 show the common pattern where memory is used
> unknown to GC. data in directory 5 probably another issue where there
> are a lot of dead strings.

I've looked at the data, thanks.  But the most important information
is missing from the data you presented.  The case where you have 570MB
in strings could be interesting, but without knowing what you did in
that session, it is impossible to say whether there's an issue there.
It could be explained by the live Lisp data you produced in that
session.

So what we need is the following, for each case separately:

  . the size of the memory footprint of the Emacs session
  . how long was the Emacs session running since it started
  . 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

In general, that old bug is closed, because after making a single
change that did cause memory bloat in some usage patterns, we
concluded that the rest were user problems caused by messing with GC
thresholds.  The glibc developers looked at the data we collected and
found nothing that could be interpreted as a bug in glibc.

TIA




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#49656; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 20 Jul 2021 07:20:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 20 03:20:42 2021
Received: from localhost ([127.0.0.1]:60893 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m5k3W-0007fj-0q
	for submit <at> debbugs.gnu.org; Tue, 20 Jul 2021 03:20:42 -0400
Received: from lists.gnu.org ([209.51.188.17]:37936)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <enometh@HIDDEN>) id 1m5k3U-0007fc-De
 for submit <at> debbugs.gnu.org; Tue, 20 Jul 2021 03:20:40 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:44894)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <enometh@HIDDEN>) id 1m5k3U-000081-8S
 for bug-gnu-emacs@HIDDEN; Tue, 20 Jul 2021 03:20:40 -0400
Received: from smtp6.ctinetworks.com ([205.166.61.199]:59514)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <enometh@HIDDEN>) id 1m5k3S-0003Pk-Lk
 for bug-gnu-emacs@HIDDEN; Tue, 20 Jul 2021 03:20:40 -0400
Received: from localhost (unknown [117.193.82.5])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 (Authenticated sender: enometh@HIDDEN)
 by smtp6.ctinetworks.com (Postfix) with ESMTPSA id A30AC84B2C
 for <bug-gnu-emacs@HIDDEN>; Tue, 20 Jul 2021 03:13:32 -0400 (EDT)
Date: Tue, 20 Jul 2021 12:43:31 +0530 (IST)
Message-Id: <20210720.124331.173592885202931943.enometh@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: more data on #43389
From: Madhu <enometh@HIDDEN>
X-Mailer: Mew version 6.8 on Emacs 28.0.50
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
 boundary="--Next_Part(Tue_Jul_20_12_43_31_2021_790)--"
Content-Transfer-Encoding: 7bit
X-ctinetworks-Information: Please contact the ISP for more information
X-ctinetworks-MailScanner-ID: A30AC84B2C.AB65C
X-ctinetworks-VirusCheck: Found to be clean
X-ctinetworks-SpamCheck: 
X-ctinetworks-Watermark: 1627629219.79031@PTDsX+Zq8uJgsHH7YPIbdQ
Received-SPF: pass client-ip=205.166.61.199; envelope-from=enometh@HIDDEN;
 helo=smtp6.ctinetworks.com
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

----Next_Part(Tue_Jul_20_12_43_31_2021_790)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is the emacs memory bloat issue. I thought I had unarchived the
bug earlier but it seems to be closed up again. Should I open a new
bug? Its already got a 1000 posts on the bugzilla page

Over the past few months, I've experienced the memory problem a few
times.  I wanted to share the malloc info data I collected on 3
instance and am attaching a tarball with 3 directories named 4 5 6
which include malloc-info, memory-usage, and memory-report data from
emacs exhibiting the behaviour - after all buffers are killed and
after an M-x gc.

Directories 4 and 6 show the common pattern where memory is used
unknown to GC. data in directory 5 probably another issue where there
are a lot of dead strings.

I'd be glad if/when experts can find the time to take a look and see
if it offers any further clues.

----Next_Part(Tue_Jul_20_12_43_31_2021_790)--
Content-Type: Application/Octet-Stream
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="madhu-emacs-malloc-info-data-20210719.tar.gz"

H4sIAAAAAAAAA+xda4/ctpL11+5fQfjeD84k3eH7YdjB2o7XMDZOFvHNRYAgCDQzmple92PQ3ePH
/votSiRV6q7WtG+SucBmBMSjlkiRqiJPFYtHlUV1fnUzqRfV2WayqObz1dlktrxYTc6rbTWRXAru
RPj6we86OBzOmPav1c1fodu/6XggNBTRVmupHnBhFdcPmPl9zR533Gy21ZqxB4soiMFy9XpzFx26
22NxlP5/fPns2zcvp6v15b/SRlSwTfom9C+kEkX/ynLQv3PaPWD8j35Z6viL6/+ELerFav2JRa2v
F9V2tloyOGN/00r5MB6fnLCz1XJbL7eb8flsXZ9tV+tZvWG//HIxm9eP9a+/6F9/zb/Mr7+Y7pf9
9RcLv+rq7Kp5RjVbjrdX67pm8fbm8XjCGBpz04+LOZuwi/Vqwd5MPuJbTcmmn5ObTXVZT7cft2zS
lUS3UNF1fb1ab9uybLdwd3M8fr1Mnaw2NWvmAvtQbVgcGdv6nFWb8d++fP7y1evvf3v74wu2uRq/
efbddz+8+O3Zjy+/f/bbm2c/P5Wp2sO//8dDKPzy+29j0UZ6y9W23kCvsPA0q5bnzMKjVh9YBcJZ
LEDs19V2W6+X7MNVva7ZzbI6O1vdLGMP1vVmdg4qGGdlbVgjnCre/HA1g77DJWiJvZ9tZqfzmm1X
7NWLKWr2EzNNc5vYXnzPtpVt828V/2NzqL+6YOd1dQ7vvp4tLzfT5hXad3sPEwBGx/jV9z+xl80V
6ad8ajh7dHozm58z8RX76O1vVk+uzybz2fLm4+RyefMV+xl6s5q/m22/gpZn61V+EhNTYaccClQf
FDR5tl7N5+y0Wm++GI//3RPjL3Ich//6d3kAR9p/JZV2zppo/7UR9/b/Lo5j9b+Lvp/Txi32H1rR
nf6FewCtWnFv/+/keFWtT0GlYILmc7ATEZVBIFswzo8egc3egLESloWgjPXMes69+YI92nxanK7m
YMfgmlbcMulUvNwaDaYkA3WCE8e00MKVO5PTT9v4QChunPcq1nnfWKe2FQ9uf7k02YA92jDPJDxD
ccUkPNNYuH8xX1XNHSHA+IigPVycgaFcv6+gU8YyGE0SKqpgxBfROl1cgPLgLSQT6gswLuzpNyNh
pvLNc/boSyb4VMNZtHtfgB/E2vcej+Q06FRCTv07VCK9/3gEN1QqMpUWPyTJAp5imyLlUisEqAqW
s72eRACXbPc0r/DTsEjGIz8NsTuxHLwE7lgrmvGIOeve5X55/KQip6bz9l3TgySh8fgfq201j1fm
s801W53+D7S7ecwCn4rYsfnsfc2cib38qvUThJ7C40Gkz5tHsHWDIdmpbODi8Vio0oIJjSS3TTuP
jJ26tgeX1TVYfdYcb2f/W49eVdej76tFPU4XhXR85IwYnbypN/Gxm5N0h1lnQJtOj05SJ76twdec
owLKj4TwUOzkdduRcktLORLBi9F5fXpz2QPCXES4WCSokc5XmHdwRYXRyYvV4npex2nTtcYYHwlu
uRuxkzez5QxanIjeXcnh1suzqxV7tq4rRtwEsHmPelmuv63eg8f33/PqrN7s3DW691C+Xzl3ZueW
EZaD6Kqzd9s1PPfk3vX6Cx2faf+7VdNntHGb/XdO9v0/KblW9/b/Lo6Xm+1s0Swj2yXdmxa4f2qW
0gATAPaWvZk9Z+wHACQYIOyHxij0C7JoB1K5H+sGvM7Zo+c3W/bTEgQHlqdXK5ZXU9OWLw+CKs8/
sVfz1SmYhn9W61kFC9lNhCo3FWTZt40ZBjicbcDoMW3UVLP/igVbO5bMwU5Xo0nEpV4vogP0ojq7
qhvTMx6nzr4Fk5vEoHx+vbfJrke7MPXttX8mA86iPVbttRetEwHNgRuRqiavgXkbprztwutijqGy
BZk0V9uOT9p+NA8Bk9/e+s/Wwo+/q9ZgA7epKFwA/8jlF2sGM1QzMgsEGz6tcjsY9ZvrqfSO4Yp+
SXuDtJLw0qlz0UKCN+XbX02x6Xx12epQ71x9Ir+JN0zp4q4xVVOXXmdn8dHeFKlazx+QWQT7tlDk
lzhJA+LHBsyae5yqJnZv7VlfdA9ZbHQVmdyisW5ot73S7egAvZ5PrmAktxOk6W5z4++xl/CCkxju
uYyCuAatxQtL8I9gdICXC6OzafHL+QfQy/KmmrcI7iZiwif8SyikQ5bYJczJCdRfbifVejs7m9eT
Kk4hGJg+ZG1c18vz6K3eLM9Xk/au1Ta3EyNW1RL113iTHz97/2kCD5xDf+ER0I3YR8XLrLsA8U2W
9YfJxRr6PzmvL6qbeRzl0ss8kK7q+XW8A+KL42FyvYbzj/FBUpXBCECxXlfQuLBlBG5ARZPrqKH8
TkKXobJaw9hdbuGR8UmiG9ZNl9/P1tsouOyqMpBZnqaXDSqBaK97lz/Mzi/r7aR3F0SYnno6O93W
HyfwZ17FE2galJe6xXyZhW2DjTbRAID7SWDzD48fJ6XmhQfcLiO9UefmBhQCT1+szuvcEZ6FcrZq
VLn5tNnWi9SB5OUdbf/7cdrPsjG32H+nhS32H5yBuP7XXNzb/7s4nrSKzSHZpw/Fw2/GT67q6pot
108f8vhrA0ZxE7G6OWsi6U8fKvUQVnH5L9hROA3cGPOQNVFreJLwyjz8ereiDm3F9m9TUVqhrS4V
jVJ2v54Xbb32b1PPS2181x4Xfr9acG219m9TTYSuLblfQ4j0aumkqWNs92LESwmZ3iqdtK8VXAhd
S0oQ9bRJ9dqTti2A4cBLRc0t1Uub5JFO2hZhWhnZVRVKwa/9ui4JJZ20daWWpuuukNYRNUOWTehk
o6W2XZuSalHyJJ900upB6ICkSohVyiSedNJWUwZW/KWe5YqoqJN00klbUXspUEVBtWiSaNJJquhk
lHLuqaNadEky6aSpGIyMEk71FAz5/Xo+S8Z3kjFScaQKT4wcxZNo0kmrCRsc0r7RRD2ZJJNO2nrK
CzTAhbKEaJRyeco71FPtcFeNIUaNMhksTCcbGWOJnXCMJYSjbBJOOkmdlV45BDOUOpTP4vFoYmmt
0MQSWhACAtOTAIoL9JrOCYsEJAiE0iIJKJ20Y4dL49GUbObKftWCiggWm/PcIvGKokhHIaSyMMqH
4E3bPMS1RUMuKG2HqhmXYTGftYJpfhzupLBFnrCot50upFAeTL5A6oAZQEKHyaBTTtMAan4dblva
rqbFNY0SfvBl4X6eluW0NXHtrwGlKJ6hRymDpqYE9wbBKzVLbMhWJEa6u+6K4JUWQ+bH8DI5LTfI
BAlQD8JYYqI4z7OCymlTNf0aUK3T3BfdCo8gWjkT+KCEYVSEPHxNNFsIpmGpYn1noikQc8EXiAeY
E96haS6DNs6o0H/tJ18nP+ZJG3zefrqunz68qDbbUg7GYiwTT77eKbeuUTkrbXy7tqw02ip4l7aR
1sdOlc5u1mtw+nNJx52y0rfQ0S+5qD6WUg7eHlyAxpd5Um1gsVenUk2H6Kf1yi2u16ttfXag4a+j
d4edPHHQycuApiR2EwYHcZpw2nc1NB8auxn5ogOYhx7XCN73q9iE7Z4j/4wPdYtwOsGoD82L3AaC
LGwhj/JPhR1EYsI1DW5wxlGeqbgFgCnPtDkfAE7KCZJmsG9SZ9Xns6R8td+9m+Vm1TBrdpxg2fee
lfjsGazKFBZO+uFZHF3BVBY8bOVvnb/geApLFEOTFxU5PHMPFdqdtofKbW5O49zdlHK9af2HyAYQ
LrqHBeGcNqFdv/TqLBbVdVenlA+SO2coUe0jooZFkte3ISI47twQSLeLiOhptyEiKpqiG9/8BXe+
jov/2Lvg/ziw44D8tuX/8Hv+z10cx+r/z4v/Cees6+s/Mj70ffzvLo4/Mv4nYD2HnG5BeFWEH6bx
ipxY/xGOmDDGoziHVIEI/BH+mHLCdR0Ek3ZcuFA4HG6QRztmYDeR70M5sqRzBqsX5Go5RYiRDBtK
xXH0lXo7OmgIr4dU4I4NGArFQxd9dcQyjYwWxthWJxbpKF+SjBZyi9bPhqpGRwuD4civOTZWKDmq
Zqi4BOUkG+5RZEFQ45IMFAojfSdLQwSXyDihiFGUbkBTkQwqTAjyQRqnNEdGCQXXSqJggjw2SKgc
oPvwTCBDhJHz1b0etSlABgiFtdygaX5kdFB6DEWUVMjQoNU4MHh0WNBwIQdfrayn8HJKGIHmOLm9
QkUSlZLSDr9ahlkcoxNK+641SQCKziire8teZboFvKJayzCrMc7qgKKBiphypoQgEcxqYxFceqKT
RpZAEx4kKmBjRVTLIGswyFqHxxbVWsZYgzAW9IbCDZKIUJgMsQbvyRiFYEETkiwRzl5k1PIgB6vZ
jLAWI6xSCNAlgSY2I6xFCCuNRaigqXhNRlircUjdoPCIp1rLCGvxXozyViJRkvGhDLHW4XCxt2pQ
4TZDLI6LgxFHUWZFaM5liHUIYpXnCGKpjRiXIdYhiJUaBsrg1HEZYJ3C44SjjVCyWsZXh7dgtEdb
DJSj4TK+OosjMyGg0AwxB1zGVxyWBX8IBekopPQZXz3G12A9mt+EAnwGWI8AVnGJnVGqWgZYjwAW
wBbBuSFGpc8A6xHAQhdt1xq1X+dL0BIBrAoOb/RSIilubM+P9b4bk5rQm88A6xHAGkCkbnBRrlDI
ABvwFo/kePeBkGTZtwgIYLVXyHhTkgwZYAMC2PjBgMF7mIQdCBliQ9+N9dhaecI4Blfce4wowQm0
00HJM2SYDQhmlXa3GGPBM87mszTImvh+p0Bqf59nrIUlOHYAAqxi8IYr1V3BM5TBggTBBOgELWUk
5cAJkZECXOBOugGgFA1wqk2Zp6GQaIgbmBp+cIgLmce4UHgZ5ALarHdUV1VZBqne7p7EaqGWQbqo
RSPT4rTDWxWUUnS2LOCwo+1zgF+E2tQCymTYFgZBojXqFv9dWF6WbBhvYCGLAJ9YZoATnIWD92vh
DcWwayBcWZQ6NEvAN0Z7cpJq0ZXlnkd2HpxBqYZnic+GXgSOR45GDgIp1ZBtaN5MTMsbqZF0BLXL
D0uzvFjkeLsCOmvwop1AO4DDbnmKtm5gYYZ2LDS5Qi2BAtlbgYNF5TgKQi0byxpc4uWtFxLNaMrM
yW59i5eOYEKsG1SLLGtHiRdlFoy/H1SLLKsyiZc8UbJoBJEr8W4PCZk7KzTaiaZAS5YFhcTOupbY
KpO6LN66xJ4wOPkWbV9Ty/HiCkvsZAIS8FtaLF6mxB6cENagNTIF6rL4cBL7Rw6GAx/ua3GQJHY+
DHj7aFVOcpPK/n7o7R46h3aBKRCRxbZLbDHBA8eapBg/xWLC6MOUPcfRKo+kJ/GMzUogbPYAIogt
JilDokSJWhiEIxaaRCyGyBkh4hYZRzIZIu1gx29ZUFUCDDQvq2C8eBPWWY9Gn+YkiSeLyQgEmTBu
PfLVBIUHRmTQhLHvkJz61BZLrYhtnp8WBywVLNzR0ooKPNoSsbS9NaAOEjmJnsA9W1aBTvQ4MQYw
f9AeOdEtXvB8ie/ZvWigli+2Cx4jmAZHmCMOADUIfQl5eryIjKM6cBzvoVz9spAMskc9U1Z3VQ3F
cS2uV8C2HtQrUaNUm6Ez9lz21vRC2GHMhQqFgcPxGtZw2wDOQIwEKnReZo8w6QCz0YAg3cUSCoVR
h82+8Voh7pug2GRQpTP8OETmtIWZgeIYVJw/mv4MpRqbKCVh+ntMLaRAUXd8NN+bBjCyjbXDPZe+
WA4lcUQETJFVKHJGwpR0XaQUL1wVvIbGLk8g2ZS2rJzgPdHgBHBSHrnpgiLjAtDl99aqt5gBt9kh
mCSHGfSweLLlPIcn9TAnJ+4tFhNmgkUagzVCkJjVTft64KGXMCBMRKxyzz1YE8w/p2iT4FeUqIaR
wXLMgQQvAwSoEZApl7W3S5LpVkkSx1qbH1gCfyDPDfAjaqstKyUsz2CoHEHrAD/OxxROt/A6dood
JnYMFdxlduyU/QyyG0Fd035odBHMNfQVwwGyU24FR8YUJrK2k+AILcpC5xFyWI+yUHO8cq1P8P+Z
6HS8YOJaN+ABDsgaVz27lXo8J9mRiLimyJzEbAgAgW1AYXA2oGLDs+FQQWo2oLL7RKej+R9/av6X
wv9QxjX8D9DCPf/jLo7j8r8I2+iExU+6wJXoZ4Dx8dM9ZrzrZ4AxKn6nwyKL3O5ngFFgPGH2yX4G
mPgZWFD7KWBiIhcbDBMGvGjPcQ4YcJUd/OPDbg4YpZSPOWCE17s5YGTOASP1NGd48U2Gk70cMGrq
TVtCuqmhc8CUrC1yqjWdAyY07ezlgJFTqXdywKiUaqVJOiMO54ARZppzwED7VA4YMXW+5KbRh3LA
iGNzwIByZMkBwwT3JQeMUtNwew4YWVqAJ6EcMCpMw3E5YOKOghjBIoyPdj8izzcF2P4ROzmLX8GC
ChOrafJhtX6Xk57Ebynah2BOG093wVe17d3eU7ZRafgpzLownHQGlrZQQAYiYY2EahJmh9jPR8Og
VkyINep9PJ+eOIqxyoNZXjSMxKG8MsLz4Yw06GP1fzcs3R93dHym/f9z8r9wW+w/rOjb/C/39v9O
jlvyvwDMT+Ux+V+iDfis/C/mM/K/+JxoZTj/C4yao/K/8Jy+oS11TP4XbaZuN/+Lkjl1R5f/JToU
u/lfVO59yf8Sk3uka738LyZnTklJXpo0OZZMCUPkfwGLs5d5pTWPXeqPw6ZRy5IUBtkkUR65mxKm
JJfYtaIH8r9Ysgt9u6rzy9IJX1xOWrNvcEuujN1sMKXRz8sGo4gELgNpYg7mdrG/M7eLAOTMerkB
iM4ZX7y4PZnLUWlhrNFZkXTeFlvUeThvS5BZYAN5W5zPwnsdDcwWxswSBsKhlC7e51lKpHSxLr/+
XiIaWCKUUTRbgr+cM6Lcng+Gu/yqRPIbAYrQw9liXJbkd9U/6p+hze1VllK8XcZoP5lMufyvJ5P5
He7acfbf3MX3PxZ8BKEkb77/Ue7++5+7OI7V/5/4/Y9WwvT1L2MCinv/7y6OP/L7H93jtIMOSeZ3
CrIjNpxpuFR5/4liBdBMYGEDylkhHLV7TDGBXdACf2BO1aOowJZbhRjL1JYzRQUGO4wICIKi2pBc
YKcDYlwJfiwZ2AmNNvIDxVimyMAmaEQHceS2OEEG1l4jZrslM0wQZGBtFdo2pCgDJBk47kprJEzq
4w6SDuwsJswFQpYkHVgILeQthAqSEBycVXhvkeonxQgW3BiFc6JQDGSKEywANdE+oiD51RQr2HuP
vsei6BAkKzhY5/DeJ0UuoGjBTmJWHzVnaVqwVC7gWUTsx5G04LjFgzfmPcUnJmnBoAn8ZQ9FyiNp
wcIaj4iAgsyjRRODhfEap3OgyNaHiMHWeo74z8KSHyrSxGClHf7cTZGMSZoYLIPBPG9J0mZparBU
XCDeLMmvOkAOls7w274COUAPluBpoA4LR7VKE4Shatz+7kRMsWBpirC02uOdekdpliYJSwABvBFN
fSx2gCYsTeilg6NSTx0gCiuuFLJ25Lw5QBWWDmwxIr9Rmd0OkIXB/ZO3KoemC0vle0wU6iOrA4Rh
JaTBGVEo7tshwjAYFoudHoq6SxOGPagbjWFNpqOjCcOag/1EYiL5QjRhOEZbEfEXcPVoyrC00F80
mijH6QBpOCa/Qp9eC4qVf4A2LIPA30SRFvEAcVjBcxD3nG6Vpg4r0JQTt4iJJg9HohZyicjPXQ/Q
hwGnHM6XQyYMpAnECrqPUYLMwkgziBUHkEWtcpIKTHKIZdyYxcx1ivZGs4hVkAp/dkNS0GkasQY0
wh2mvjk8QCRWupVfUQ7FdqOZxC5yZxCTmBpNB5jEkTdlHEqcRdG0D1CJwU+2Hg1FTw3FA1xiGVT8
X7Z07jmF4ge4xCrmPcDpMilO+gEycdzbNK5zniy1FDzIJtYh/F97Z7PbNgzD8XP2FD4XaKAPipIf
JyiCtSjaFW0P29uPciKZsinbWZsO2MRjIieOLYmk8yP/HCeWSv4qPLENtGQYYe6k7KdCFNsA2DN4
X+xkyZlitgzAGR9YTSRKa55TxbywJuigWWcDVGKJo8gV0+IDZPkQStO5xhXbeI94DiaF/jJZ7Gij
QjafndQ0osYWowmW14ShWNpT0MVsn8OYkTFO10l1flW+mMILR1eBt7sQY6IaY0we0FrN2tMBSs8B
SsqY11xQUg+KpRVWDCLpoLxnQuGW4gkUaQlKIRIdlJ1/KPpTIMW+DJuXfGkIY9u/gpDu0fACHhEz
zlm7LRZmZH14M2TpOUHR/5J7inhGvFBZIpQZY4wOuEt1tMfz2pE4M4QHTDmA7hPxe847e7CueMwk
ztbUgnXwvAVgTdkn8nJpkXE2Y6sUigz47hA3JVYYJDaRxriWUzhRxJiewmzHqgfE8JQS6+x5el+0
4hyIX17/Lj3fcRRLp11C+Z6neDELNZolPunXT6hYqbn39bhmS9tXpjhtiCmsPyUpy1gsGeWOcHKi
dTQ2dmUB5+xav7rJ5y0jsuXYj/XwDCuVMwIJrXlDCWmvP89ePX6L5g+DN95Bm3FzHXfpZXg3DaXp
1wts7b8FNV9yZeL8tuP8pu1PefCfSzXHCal7h7BySWkxQOyFscb4Tz5vdTGwsf9x+8YP2+b//67J
fzud//+jyOWk/4nt/7+vsI38t3KObk4H5DlQTQRAKUbwXZjIfzrQgFGSCswc/qa0jDYZC3qi/0lT
TYC/DWUetN47g32wmrPflNl0GryfyX9aSmnppMHM5D8hy39i4qz9HnxF/lOdRqi9rch/DuRzHNJ5
X0DYGf2m8+ll+U8IE/TbqL1PILnCOvqN+6DO6LcumfRR/hPgNKKj1Oyxgn7bzeg35UAj+k0B6ij/
qbag3zDKf4aBVT+j38ZuRb+jC1M79MHskrZZNA3W7owxuJururMRNN92AuYVjVLLHcX4YU5iU367
DHjHo+LzRQHwpt3tBJHfvN29Ht7v7kfYOn5fFBPtbt4fXiaAtl4CtE3P3jSb1T2raqLWr+mFFojb
396oml3FLvT/V+G/0TL/b+zAf5vG/3yJrfDftNfv1Sb9T5NY13Wee2CHL2DFO0wM+or+Z68S+vnJ
/LcbxPgm/Lcx6TWm/4lJqnRJ/9Mrl0604L9rsPdwCUo0XNL/9JmKTT6y1wkelvwjuMxAM+dnszbp
3GXqTEYXjq1P4OvUe2Fitqeeq8prZ2HSuc81I5WdXOeC2ufFDHcnynlWyW73Jaqd3mUAf0Y6x7W5
CoG7Xi3y3WBDIYL5evx+/Hl7f3i7/9ZZnQVh6+y3xG47lZVb6e7dHV5unx7oqOPP9+NzpAzflihs
49IkEMBvlc/o1+H58fbp+DxM81w48PhAv28Is4f3X34M8a48JL6aBUdLJju//CGBzywT+gcCny3e
atasWbNmzZo1a9asWbNmzZo1a/YZ9ht+tEEpAKAAAA==

----Next_Part(Tue_Jul_20_12_43_31_2021_790)----




Acknowledgement sent to Madhu <enometh@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#49656; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Wed, 21 Jul 2021 12:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.