GNU bug report logs - #37006
27.0.50; garbage collection not happening after 26de2d42

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: Joseph Mingrone <jrm@HIDDEN>; Keywords: patch; dated Sun, 11 Aug 2019 12:41:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

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


Received: (at 37006) by debbugs.gnu.org; 15 Aug 2019 01:37:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 14 21:37:55 2019
Received: from localhost ([127.0.0.1]:50060 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hy4i9-0006yn-MY
	for submit <at> debbugs.gnu.org; Wed, 14 Aug 2019 21:37:55 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45686)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1hy4i7-0006yR-RR
 for 37006 <at> debbugs.gnu.org; Wed, 14 Aug 2019 21:37:52 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id F073D1616A8;
 Wed, 14 Aug 2019 18:37:45 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id jqtD4uWJ5ryN; Wed, 14 Aug 2019 18:37:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 870361626EF;
 Wed, 14 Aug 2019 18:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id bOtED6xe87ZS; Wed, 14 Aug 2019 18:37:44 -0700 (PDT)
Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com
 [23.242.74.103])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 56E441616A8;
 Wed, 14 Aug 2019 18:37:44 -0700 (PDT)
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
To: Eli Zaretskii <eliz@HIDDEN>
References: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
 <83h86nu0pq.fsf@HIDDEN> <86pnlbphus.fsf@HIDDEN>
 <83a7cft8qx.fsf@HIDDEN> <868srysb9x.fsf@HIDDEN>
 <83wofis508.fsf@HIDDEN> <2687613f-ba89-25cf-9517-5311106aef9a@HIDDEN>
 <83ef1prly5.fsf@HIDDEN> <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@HIDDEN>
 <83v9uzrasm.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <18886155-d96b-ae07-1df2-1b1d58a8bbb2@HIDDEN>
Date: Wed, 14 Aug 2019 18:37:44 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <83v9uzrasm.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 37006
Cc: jrm@HIDDEN, mattiase@HIDDEN, 37006 <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 (---)

Eli Zaretskii wrote:

> However, I'd rather we don't invent new data types unless really
> necessary.

I did that yesterday, in commit 2019-08-13T19:20:40Z!eggert@HIDDEN 
(b80559be212292d44ce14ca5e94505cab4d9a868).

> gc-cons-threshold is a Lisp integer, a
> fixnum, so it cannot exceed EMACS_INT_MAX, I think.

No, (setq gc-cons-threshold (1+ most-positive-fixnum)) works and does the right 
thing. The variable's value can be any intmax_t value. This is useful for 
quantities like GC object byte counts that might not fit into fixnums.

> Can we use for this purpose the existing trapped_write
> field of Lisp_Symbol that is the base for implementing Lisp watcher
> functions?

Don't see why not.

> With the old code, whenever memory-full was non-nil, and
> consing_since_gc was more than the size of cons_block (about 1KB on my
> system), the very next maybe_gc call would actually trigger GC.  With
> the new code, no matter how much consing happened before memory-full
> became non-nil, we still need to cons 1KB worth of objects before GC
> happens.  This 1KB might be critical when we are out of memory.

I don't think the scenario is worth worrying about doing a GC now rather than 
later. But if we go the trapped_write route, this issue won't matter since the 
GC will be done quickly.

>> Immediate-GC might cause GC thrashing, no?
> 
> Not sure how, can you elaborate?

When EMacs is low on memory, if we're not careful Emacs could GC every time 
maybe_gc is called, which will be roughly equivalent to Emacs hanging and doing 
nothing.




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

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


Received: (at 37006) by debbugs.gnu.org; 14 Aug 2019 16:07:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 14 12:07:08 2019
Received: from localhost ([127.0.0.1]:49601 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hxvno-0000Ja-1m
	for submit <at> debbugs.gnu.org; Wed, 14 Aug 2019 12:07:08 -0400
Received: from eggs.gnu.org ([209.51.188.92]:35339)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hxvnm-0000J7-7T
 for 37006 <at> debbugs.gnu.org; Wed, 14 Aug 2019 12:07:06 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:58594)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hxvng-00052Z-HT; Wed, 14 Aug 2019 12:07:00 -0400
Received: from [176.228.60.248] (port=3336 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hxvnf-0005zm-TI; Wed, 14 Aug 2019 12:07:00 -0400
Date: Wed, 14 Aug 2019 19:06:49 +0300
Message-Id: <83v9uzrasm.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@HIDDEN> (message from
 Paul Eggert on Tue, 13 Aug 2019 12:32:24 -0700)
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
References: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
 <83h86nu0pq.fsf@HIDDEN> <86pnlbphus.fsf@HIDDEN>
 <83a7cft8qx.fsf@HIDDEN> <868srysb9x.fsf@HIDDEN>
 <83wofis508.fsf@HIDDEN> <2687613f-ba89-25cf-9517-5311106aef9a@HIDDEN>
 <83ef1prly5.fsf@HIDDEN> <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 37006
Cc: jrm@HIDDEN, mattiase@HIDDEN, 37006 <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 (---)

> Cc: jrm@HIDDEN, mattiase@HIDDEN, 37006 <at> debbugs.gnu.org
> From: Paul Eggert <eggert@HIDDEN>
> Date: Tue, 13 Aug 2019 12:32:24 -0700
> 
> > OBJECT_CT_MAX should have the value EMACS_INT_MAX.
> 
> Not if EMACS_INT_MAX < INTPTR_MAX, since object counts might overflow in that 
> case. However, I take your point that consing_until_gc can easily be made to 
> hold any fixnum value, so I installed the first attached patch. This is to some 
> extent overkill, since these variables should not be assumed to have this sort 
> of fine-grained control, but the change is tiny so should be fine.

Thanks.

However, I'd rather we don't invent new data types unless really
necessary.  I think we should simply use EMACS_INT (see below), but
even if we end up using intptr_max, let's just use that directly, not
introduce yet another type which we will have to look up every time we
read this code.  And likewise with the corresponding _MAX value.
Using a non-standard data type makes the code harder to read.

> Come to think of it, the limit should be INTMAX_MAX not EMACS_INT_MAX since 
> gc-cons-threshold could exceed EMACS_INT_MAX.

Sorry, I don't think I follow.  gc-cons-threshold is a Lisp integer, a
fixnum, so it cannot exceed EMACS_INT_MAX, I think.

> The idea would be to have a type that is like struct Lisp_Objfwd but with an 
> extra member, a function to be called whenever the variable is accessed. (Or 
> perhaps two extra members, a getter and a setter.) This could be useful for 
> other builtin vars, I suspect.

Ah, okay.  Can we use for this purpose the existing trapped_write
field of Lisp_Symbol that is the base for implementing Lisp watcher
functions?

> > How else would you succeed in reacting to the change "soon enough"?
> 
> There are other possibilities. We could have a timer, for example.

I don't think timers are reliable enough, as they can be deferred for
arbitrarily long time interval by some Lisp that takes a long time to
finish.

> >>> We must also notice the memory-full condition there.
> >>
> >> memory_full already does that, no? It sets consing_until_gc.
> > 
> > It sets it to a positive value, so no immediate GC will follow.  The
> > original code was setting the threshold to a very small value, so GC
> > would happen immediately.
> 
> Are you talking about the change in commit 
> 2019-07-20T02:40:03Z!eggert@HIDDEN 
> (26de2d42d0460c5b193456950a568cb04a29dc00)? If so, I'm not quite following, as 
> the old code did not GC until consing_since_gc > memory_full_cons_threshold. I 
> expect that the idea was to not thrash doing GCs when memory is full.

With the old code, whenever memory-full was non-nil, and
consing_since_gc was more than the size of cons_block (about 1KB on my
system), the very next maybe_gc call would actually trigger GC.  With
the new code, no matter how much consing happened before memory-full
became non-nil, we still need to cons 1KB worth of objects before GC
happens.  This 1KB might be critical when we are out of memory.

> Immediate-GC might cause GC thrashing, no?

Not sure how, can you elaborate?




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

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


Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 19:32:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 13 15:32:35 2019
Received: from localhost ([127.0.0.1]:48658 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hxcX5-0006K1-0L
	for submit <at> debbugs.gnu.org; Tue, 13 Aug 2019 15:32:35 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58548)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1hxcX2-0006Jn-Cf
 for 37006 <at> debbugs.gnu.org; Tue, 13 Aug 2019 15:32:33 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9DF72162732;
 Tue, 13 Aug 2019 12:32:26 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id UVck_yB_e_Yq; Tue, 13 Aug 2019 12:32:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 38800162733;
 Tue, 13 Aug 2019 12:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id JvsQf8kSbgcL; Tue, 13 Aug 2019 12:32:25 -0700 (PDT)
Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com
 [23.242.74.103])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id ED71D162732;
 Tue, 13 Aug 2019 12:32:24 -0700 (PDT)
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
To: Eli Zaretskii <eliz@HIDDEN>
References: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
 <83h86nu0pq.fsf@HIDDEN> <86pnlbphus.fsf@HIDDEN>
 <83a7cft8qx.fsf@HIDDEN> <868srysb9x.fsf@HIDDEN>
 <83wofis508.fsf@HIDDEN> <2687613f-ba89-25cf-9517-5311106aef9a@HIDDEN>
 <83ef1prly5.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@HIDDEN>
Date: Tue, 13 Aug 2019 12:32:24 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <83ef1prly5.fsf@HIDDEN>
Content-Type: multipart/mixed; boundary="------------4523E105E1821A76D13A372E"
Content-Language: en-US
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 37006
Cc: jrm@HIDDEN, mattiase@HIDDEN, 37006 <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 (---)

This is a multi-part message in MIME format.
--------------4523E105E1821A76D13A372E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Eli Zaretskii wrote:

> OBJECT_CT_MAX should have the value EMACS_INT_MAX.

Not if EMACS_INT_MAX < INTPTR_MAX, since object counts might overflow in that 
case. However, I take your point that consing_until_gc can easily be made to 
hold any fixnum value, so I installed the first attached patch. This is to some 
extent overkill, since these variables should not be assumed to have this sort 
of fine-grained control, but the change is tiny so should be fine.

Come to think of it, the limit should be INTMAX_MAX not EMACS_INT_MAX since 
gc-cons-threshold could exceed EMACS_INT_MAX. So I installed the second attached 
patch to do that.

>> I don't see why the threshold needs to be recomputed on each maybe_gc call. I
>> suppose we could add a new builtin variable type, so that the threshold could be
>> recomputed whenever GC-related builtin variables are changed; that should do the
>> trick without slowing down maybe_gc.
> 
> I don't think I understand what this proposal means in practice.  Can
> you elaborate, or show an example?

The idea would be to have a type that is like struct Lisp_Objfwd but with an 
extra member, a function to be called whenever the variable is accessed. (Or 
perhaps two extra members, a getter and a setter.) This could be useful for 
other builtin vars, I suspect.

> How else would you succeed in reacting to the change "soon enough"?

There are other possibilities. We could have a timer, for example.
>>> We must also notice the memory-full condition there.
>>
>> memory_full already does that, no? It sets consing_until_gc.
> 
> It sets it to a positive value, so no immediate GC will follow.  The
> original code was setting the threshold to a very small value, so GC
> would happen immediately.

Are you talking about the change in commit 
2019-07-20T02:40:03Z!eggert@HIDDEN 
(26de2d42d0460c5b193456950a568cb04a29dc00)? If so, I'm not quite following, as 
the old code did not GC until consing_since_gc > memory_full_cons_threshold. I 
expect that the idea was to not thrash doing GCs when memory is full.

I think the code in memory_full which sets
> consing_until_gc should be amended to (a) not raise consing_until_gc
> if the current value is already below memory_full_cons_threshold, and
> (b) probably even set it to the negative of sizeof (struct cons_block)
> so as to cause an immediate GC.

Immediate-GC might cause GC thrashing, no? But (a) makes sense so I installed 
the third attached patch.

--------------4523E105E1821A76D13A372E
Content-Type: text/x-patch;
 name="0001-Let-consing_until_gc-exceed-INTPTR_MAX.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="0001-Let-consing_until_gc-exceed-INTPTR_MAX.patch"

From a354736e1dfe5a7e4ddbb1ee7f1373be2b5bbe09 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@HIDDEN>
Date: Tue, 13 Aug 2019 12:11:35 -0700
Subject: [PATCH 1/3] Let consing_until_gc exceed INTPTR_MAX

Suggested by Eli Zaretskii (Bug#37006#46).
* src/alloc.c (consing_until_gc): Now of type consing_ct.
All uses changed, so gc-cons-threshold no longer saturates
against OBJECT_CT_MAX.
(object_ct): Move typedef here from lisp.h.
* src/lisp.h (consing_ct, CONSING_CT_MAX): New type and macro.
(OBJECT_CT_MAX): Remove.  Replace all uses with CONSING_CT_MAX.
---
 src/alloc.c | 21 ++++++++++-----------
 src/lisp.h  | 10 +++++++---
 2 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/src/alloc.c b/src/alloc.c
index c7419e2fa5..7bed3f4488 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -224,7 +224,7 @@ struct emacs_globals globals;
 
 /* maybe_gc collects garbage if this goes negative.  */
 
-object_ct consing_until_gc;
+consing_ct consing_until_gc;
 
 #ifdef HAVE_PDUMPER
 /* Number of finalizers run: used to loop over GC until we stop
@@ -236,9 +236,10 @@ int number_finalizers_run;
 
 bool gc_in_progress;
 
-/* System byte counts reported by GC.  */
+/* System byte and object counts reported by GC.  */
 
 typedef uintptr_t byte_ct;
+typedef intptr_t object_ct;
 
 /* Number of live and free conses etc.  */
 
@@ -2546,7 +2547,7 @@ free_cons (struct Lisp_Cons *ptr)
      might incorrectly return non-zero.  */
   int incr = sizeof *ptr;
   if (INT_ADD_WRAPV (consing_until_gc, incr, &consing_until_gc))
-    consing_until_gc = OBJECT_CT_MAX;
+    consing_until_gc = CONSING_CT_MAX;
   gcstat.total_free_conses++;
 }
 
@@ -5501,7 +5502,7 @@ staticpro (Lisp_Object const *varaddress)
 static void
 allow_garbage_collection (intmax_t consing)
 {
-  consing_until_gc = consing - (OBJECT_CT_MAX - consing_until_gc);
+  consing_until_gc = consing - (CONSING_CT_MAX - consing_until_gc);
   garbage_collection_inhibited--;
 }
 
@@ -5511,7 +5512,7 @@ inhibit_garbage_collection (void)
   ptrdiff_t count = SPECPDL_INDEX ();
   record_unwind_protect_intmax (allow_garbage_collection, consing_until_gc);
   garbage_collection_inhibited++;
-  consing_until_gc = OBJECT_CT_MAX;
+  consing_until_gc = CONSING_CT_MAX;
   return count;
 }
 
@@ -5817,7 +5818,7 @@ garbage_collect_1 (struct gcstat *gcst)
 
   /* In case user calls debug_print during GC,
      don't let that cause a recursive GC.  */
-  consing_until_gc = OBJECT_CT_MAX;
+  consing_until_gc = CONSING_CT_MAX;
 
   /* Save what's currently displayed in the echo area.  Don't do that
      if we are GC'ing because we've run out of memory, since
@@ -5932,19 +5933,17 @@ garbage_collect_1 (struct gcstat *gcst)
     consing_until_gc = memory_full_cons_threshold;
   else
     {
-      intptr_t threshold = min (max (GC_DEFAULT_THRESHOLD / 10,
-				     gc_cons_threshold),
-				OBJECT_CT_MAX);
+      consing_ct threshold = max (gc_cons_threshold, GC_DEFAULT_THRESHOLD / 10);
       if (FLOATP (Vgc_cons_percentage))
 	{
 	  double tot = (XFLOAT_DATA (Vgc_cons_percentage)
 			* total_bytes_of_live_objects ());
 	  if (threshold < tot)
 	    {
-	      if (tot < OBJECT_CT_MAX)
+	      if (tot < CONSING_CT_MAX)
 		threshold = tot;
 	      else
-		threshold = OBJECT_CT_MAX;
+		threshold = CONSING_CT_MAX;
 	    }
 	}
       consing_until_gc = threshold;
diff --git a/src/lisp.h b/src/lisp.h
index 63baab5d63..043f2f738e 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -3793,9 +3793,13 @@ extern void flush_stack_call_func (void (*func) (void *arg), void *arg);
 extern void garbage_collect (void);
 extern const char *pending_malloc_warning;
 extern Lisp_Object zero_vector;
-typedef intptr_t object_ct; /* Signed type of object counts reported by GC.  */
-#define OBJECT_CT_MAX INTPTR_MAX
-extern object_ct consing_until_gc;
+#define CONSING_CT_MAX max (INTPTR_MAX, EMACS_INT_MAX)
+#if CONSING_CT_MAX == INTPTR_MAX
+typedef intptr_t consing_ct;
+#else
+typedef EMACS_INT consing_ct;
+#endif
+extern consing_ct consing_until_gc;
 #ifdef HAVE_PDUMPER
 extern int number_finalizers_run;
 #endif
-- 
2.17.1


--------------4523E105E1821A76D13A372E
Content-Type: text/x-patch;
 name="0002-Let-consing_until_gc-exceed-EMACS_INT_MAX.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="0002-Let-consing_until_gc-exceed-EMACS_INT_MAX.patch"

From b80559be212292d44ce14ca5e94505cab4d9a868 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@HIDDEN>
Date: Tue, 13 Aug 2019 12:20:40 -0700
Subject: [PATCH 2/3] Let consing_until_gc exceed EMACS_INT_MAX

This builds on the previous patch.
* src/alloc.c (consing_until_gc): Now of type intmax_t,
since gc-cons-threshold can be up to INTMAX_MAX.  All uses changed.
* src/lisp.h (CONSING_CT_MAX, consing_ct): Remove.
---
 src/alloc.c | 16 ++++++++--------
 src/lisp.h  |  8 +-------
 2 files changed, 9 insertions(+), 15 deletions(-)

diff --git a/src/alloc.c b/src/alloc.c
index 7bed3f4488..14b0a7b838 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -224,7 +224,7 @@ struct emacs_globals globals;
 
 /* maybe_gc collects garbage if this goes negative.  */
 
-consing_ct consing_until_gc;
+intmax_t consing_until_gc;
 
 #ifdef HAVE_PDUMPER
 /* Number of finalizers run: used to loop over GC until we stop
@@ -2547,7 +2547,7 @@ free_cons (struct Lisp_Cons *ptr)
      might incorrectly return non-zero.  */
   int incr = sizeof *ptr;
   if (INT_ADD_WRAPV (consing_until_gc, incr, &consing_until_gc))
-    consing_until_gc = CONSING_CT_MAX;
+    consing_until_gc = INTMAX_MAX;
   gcstat.total_free_conses++;
 }
 
@@ -5502,7 +5502,7 @@ staticpro (Lisp_Object const *varaddress)
 static void
 allow_garbage_collection (intmax_t consing)
 {
-  consing_until_gc = consing - (CONSING_CT_MAX - consing_until_gc);
+  consing_until_gc = consing - (INTMAX_MAX - consing_until_gc);
   garbage_collection_inhibited--;
 }
 
@@ -5512,7 +5512,7 @@ inhibit_garbage_collection (void)
   ptrdiff_t count = SPECPDL_INDEX ();
   record_unwind_protect_intmax (allow_garbage_collection, consing_until_gc);
   garbage_collection_inhibited++;
-  consing_until_gc = CONSING_CT_MAX;
+  consing_until_gc = INTMAX_MAX;
   return count;
 }
 
@@ -5818,7 +5818,7 @@ garbage_collect_1 (struct gcstat *gcst)
 
   /* In case user calls debug_print during GC,
      don't let that cause a recursive GC.  */
-  consing_until_gc = CONSING_CT_MAX;
+  consing_until_gc = INTMAX_MAX;
 
   /* Save what's currently displayed in the echo area.  Don't do that
      if we are GC'ing because we've run out of memory, since
@@ -5933,17 +5933,17 @@ garbage_collect_1 (struct gcstat *gcst)
     consing_until_gc = memory_full_cons_threshold;
   else
     {
-      consing_ct threshold = max (gc_cons_threshold, GC_DEFAULT_THRESHOLD / 10);
+      intmax_t threshold = max (gc_cons_threshold, GC_DEFAULT_THRESHOLD / 10);
       if (FLOATP (Vgc_cons_percentage))
 	{
 	  double tot = (XFLOAT_DATA (Vgc_cons_percentage)
 			* total_bytes_of_live_objects ());
 	  if (threshold < tot)
 	    {
-	      if (tot < CONSING_CT_MAX)
+	      if (tot < INTMAX_MAX)
 		threshold = tot;
 	      else
-		threshold = CONSING_CT_MAX;
+		threshold = INTMAX_MAX;
 	    }
 	}
       consing_until_gc = threshold;
diff --git a/src/lisp.h b/src/lisp.h
index 043f2f738e..0370c52fad 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -3793,13 +3793,7 @@ extern void flush_stack_call_func (void (*func) (void *arg), void *arg);
 extern void garbage_collect (void);
 extern const char *pending_malloc_warning;
 extern Lisp_Object zero_vector;
-#define CONSING_CT_MAX max (INTPTR_MAX, EMACS_INT_MAX)
-#if CONSING_CT_MAX == INTPTR_MAX
-typedef intptr_t consing_ct;
-#else
-typedef EMACS_INT consing_ct;
-#endif
-extern consing_ct consing_until_gc;
+extern intmax_t consing_until_gc;
 #ifdef HAVE_PDUMPER
 extern int number_finalizers_run;
 #endif
-- 
2.17.1


--------------4523E105E1821A76D13A372E
Content-Type: text/x-patch;
 name="0003-Don-t-increase-consing_until_gc-when-out-of-memory.patch"
Content-Disposition: attachment;
 filename*0="0003-Don-t-increase-consing_until_gc-when-out-of-memory.patc";
 filename*1="h"
Content-Transfer-Encoding: quoted-printable

From f4974d6fe6137f436763998be27afafea9866098 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@HIDDEN>
Date: Tue, 13 Aug 2019 12:28:53 -0700
Subject: [PATCH 3/3] =3D?UTF-8?q?Don=3DE2=3D80=3D99t=3D20increase=3D20con=
sing=3D5Funtil?=3D
 =3D?UTF-8?q?=3D5Fgc=3D20when=3D20out=3D20of=3D20memory?=3D
MIME-Version: 1.0
Content-Type: text/plain; charset=3DUTF-8
Content-Transfer-Encoding: 8bit

* src/alloc.c (memory_full): Don=E2=80=99t increase consing_until_gc.
Suggested by Eli Zaretskii (Bug#37006#46).
---
 src/alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/alloc.c b/src/alloc.c
index 14b0a7b838..0548a09cb8 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -3866,7 +3866,7 @@ memory_full (size_t nbytes)
   if (! enough_free_memory)
     {
       Vmemory_full =3D Qt;
-      consing_until_gc =3D memory_full_cons_threshold;
+      consing_until_gc =3D min (consing_until_gc, memory_full_cons_thres=
hold);
=20
       /* The first time we get here, free the spare memory.  */
       for (int i =3D 0; i < ARRAYELTS (spare_memory); i++)
--=20
2.17.1


--------------4523E105E1821A76D13A372E--




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

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


Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 17:54:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 13 13:54:03 2019
Received: from localhost ([127.0.0.1]:48618 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hxazi-0003ah-Td
	for submit <at> debbugs.gnu.org; Tue, 13 Aug 2019 13:54:03 -0400
Received: from eggs.gnu.org ([209.51.188.92]:55299)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hxazg-0003a3-Lv
 for 37006 <at> debbugs.gnu.org; Tue, 13 Aug 2019 13:54:01 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:42392)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hxaza-000453-Ou; Tue, 13 Aug 2019 13:53:54 -0400
Received: from [176.228.60.248] (port=1909 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hxazZ-00027B-Q7; Tue, 13 Aug 2019 13:53:54 -0400
Date: Tue, 13 Aug 2019 20:53:38 +0300
Message-Id: <83ef1prly5.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <2687613f-ba89-25cf-9517-5311106aef9a@HIDDEN> (message from
 Paul Eggert on Tue, 13 Aug 2019 10:21:51 -0700)
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
References: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
 <83h86nu0pq.fsf@HIDDEN> <86pnlbphus.fsf@HIDDEN>
 <83a7cft8qx.fsf@HIDDEN> <868srysb9x.fsf@HIDDEN>
 <83wofis508.fsf@HIDDEN> <2687613f-ba89-25cf-9517-5311106aef9a@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 37006
Cc: jrm@HIDDEN, mattiase@HIDDEN, 37006 <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 (---)

> Cc: mattiase@HIDDEN, 37006 <at> debbugs.gnu.org
> From: Paul Eggert <eggert@HIDDEN>
> Date: Tue, 13 Aug 2019 10:21:51 -0700
> 
> > We must
> > have something in maybe_gc to notice the change and recompute the
> > threshold.
> 
> I don't see why the threshold needs to be recomputed on each maybe_gc call. I 
> suppose we could add a new builtin variable type, so that the threshold could be 
> recomputed whenever GC-related builtin variables are changed; that should do the 
> trick without slowing down maybe_gc.

I don't think I understand what this proposal means in practice.  Can
you elaborate, or show an example?

> But is it that important to recalculate the GC threshold
> immediately?

How else would you succeed in reacting to the change "soon enough"?
In the use case which triggered this bug report, setting
gc-cons-threshold to a very large number disables GC for an extremely
long time, and all that time the gc-cons-threshold changes made by the
user are not acted upon.

IOW, we could perhaps explain away a delay of seconds in acting upon
the change, but we surely cannot explain away a delay of hours, let
alone days.

> Variables like gc-cons-threshold aren't intended for fine-grained
> control over exactly when the GC is called; they're merely advice.

Yes, but abrupt changes, like to most-positive-fixnum and then back to
much smaller values, should produce at least approximately the
expected behavior.  In particular, changing from most-positive-fixnum
to a value like 800000 should cause a GC "soon enough".  If we don't
test the value inside maybe_gc, what alternative mechanisms would you
suggest to produce such an effect?

> > We must also notice the memory-full condition there.
> 
> memory_full already does that, no? It sets consing_until_gc.

It sets it to a positive value, so no immediate GC will follow.  The
original code was setting the threshold to a very small value, so GC
would happen immediately.  I think the code in memory_full which sets
consing_until_gc should be amended to (a) not raise consing_until_gc
if the current value is already below memory_full_cons_threshold, and
(b) probably even set it to the negative of sizeof (struct cons_block)
so as to cause an immediate GC.

> > First, gc_cons_threshold is an EMACS_INT, so putting its value into
> > intptr_t is wrong in 32-bit builds --with-wide-int, right?
> 
> That's not a problem, since the above code does min (..., OBJECT_CT_MAX) on the 
> result before storing it into intptr_t.

??? But that effectively disallows/ignores values of gc-cons-threshold
above LONG_MAX.  Why would we make such a backward-incompatible change?
When the user sets the value of that variable, the variable should
keep its value, and we should be able to compare the threshold with
the value of the user variable.  If nothing else, arbitrarily throwing
away high-order bits of the value is a sure path towards bugs due to
confusion between these two value ranges.

> > using intptr_t for OBJECT_CT_MAX is wrong in such a build.
> 
> I don't see why it's wrong.

Because OBJECT_CT_MAX should have the value EMACS_INT_MAX.




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

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


Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 17:29:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 13 13:29:32 2019
Received: from localhost ([127.0.0.1]:48613 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hxaby-0002zR-6i
	for submit <at> debbugs.gnu.org; Tue, 13 Aug 2019 13:29:32 -0400
Received: from mail212c50.megamailservers.eu ([91.136.10.222]:43224
 helo=mail194c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1hxabu-0002z6-Ts
 for 37006 <at> debbugs.gnu.org; Tue, 13 Aug 2019 13:29:28 -0400
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1565717350;
 bh=wDnuqTx2/XYcAgR/LZkhOCTJ9q/Yjp+Us3Vb9uIwkr8=;
 h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
 b=r/LuLFODAEE5XlGi3Vpg4aV8eSFnULfYxMb/MAdYdkEoG0ub4q/14aWxrz/00O1Oh
 jLykGHygpVslFj4lneirhxouSHJ2L4MwRr8HEOwWyZWscksXzZ+lDJqPW6cvKny1SQ
 HS283AVR90z5iYWA0sxAK/Ku6amVGo6XPPKpeYMc=
Feedback-ID: mattiase@HIDDEN
Received: from [192.168.0.4] ([188.150.171.71]) (authenticated bits=0)
 by mail194c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id x7DHT8ia017804; 
 Tue, 13 Aug 2019 17:29:09 +0000
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
In-Reply-To: <83ftm5ro8i.fsf@HIDDEN>
Date: Tue, 13 Aug 2019 19:29:07 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <468CCECA-FC1D-47DD-A690-A3CA96CBF866@HIDDEN>
References: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
 <83h86nu0pq.fsf@HIDDEN> <86pnlbphus.fsf@HIDDEN>
 <83a7cft8qx.fsf@HIDDEN> <868srysb9x.fsf@HIDDEN>
 <83wofis508.fsf@HIDDEN> <A3B3F9F1-4ADD-4565-876C-24A3E4AABC7F@HIDDEN>
 <83h86lrs8p.fsf@HIDDEN> <3E8F9821-8C8B-48AD-BC88-7191450C4D7E@HIDDEN>
 <83ftm5ro8i.fsf@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.11)
X-CTCH-RefID: str=0001.0A0B0210.5D52F366.0041, ss=1, re=0.000, recu=0.000,
 reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.3 cv=Df05VMlW c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117
 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19
 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=mDV3o1hIAAAA:8
 a=px8s3ZbfGHmYftafZr4A:9 a=CjuIK1q_8ugA:10 a=_FVE-zBwftR9WsbkzFJk:22
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 37006
Cc: jrm@HIDDEN, eggert@HIDDEN, 37006 <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.0 (/)

13 aug. 2019 kl. 19.04 skrev Eli Zaretskii <eliz@HIDDEN>:
>=20
>> Regarding changes gc-cons-percentage, the effect will just be delayed =
to next GC --- is this really harmful?
>=20
> IOW, you think that whatever this changes in user-facing behavior is
> unimportant, and we shouldn't be bothered about it.  I happen to
> disagree.

In contrast to gc-cons-threshold, we never really promised the effect of =
gc-cons-percentage to be immediate, and it seems unlikely that anyone =
would use the latter variable in such a way.





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

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


Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 17:22:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 13 13:22:01 2019
Received: from localhost ([127.0.0.1]:48609 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hxaUj-0002nN-6W
	for submit <at> debbugs.gnu.org; Tue, 13 Aug 2019 13:22:01 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36920)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1hxaUg-0002n6-IN
 for 37006 <at> debbugs.gnu.org; Tue, 13 Aug 2019 13:21:59 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id C5CD1162729;
 Tue, 13 Aug 2019 10:21:52 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id tEzleCR-qOCF; Tue, 13 Aug 2019 10:21:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id DF3E116272B;
 Tue, 13 Aug 2019 10:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id mDfK3R24W3tt; Tue, 13 Aug 2019 10:21:51 -0700 (PDT)
Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com
 [23.242.74.103])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 8D7FF162729;
 Tue, 13 Aug 2019 10:21:51 -0700 (PDT)
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
To: Eli Zaretskii <eliz@HIDDEN>, Joseph Mingrone <jrm@HIDDEN>
References: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
 <83h86nu0pq.fsf@HIDDEN> <86pnlbphus.fsf@HIDDEN>
 <83a7cft8qx.fsf@HIDDEN> <868srysb9x.fsf@HIDDEN>
 <83wofis508.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <2687613f-ba89-25cf-9517-5311106aef9a@HIDDEN>
Date: Tue, 13 Aug 2019 10:21:51 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <83wofis508.fsf@HIDDEN>
Content-Type: multipart/mixed; boundary="------------3A5BBA64323C417A2FD237A2"
Content-Language: en-US
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 37006
Cc: mattiase@HIDDEN, 37006 <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 (---)

This is a multi-part message in MIME format.
--------------3A5BBA64323C417A2FD237A2
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Eli Zaretskii wrote:

> We must
> have something in maybe_gc to notice the change and recompute the
> threshold.

I don't see why the threshold needs to be recomputed on each maybe_gc call. I 
suppose we could add a new builtin variable type, so that the threshold could be 
recomputed whenever GC-related builtin variables are changed; that should do the 
trick without slowing down maybe_gc. But is it that important to recalculate the 
GC threshold immediately? Variables like gc-cons-threshold aren't intended for 
fine-grained control over exactly when the GC is called; they're merely advice.

> We must also notice the memory-full condition there.

memory_full already does that, no? It sets consing_until_gc. Or are you thinking 
of some other memory-full condition?

>    if (!NILP (Vmemory_full))
>      consing_until_gc = memory_full_cons_threshold;
>    else
>      {
>        intptr_t threshold = min (max (GC_DEFAULT_THRESHOLD,
> 				     gc_cons_threshold >> 3),
> 				OBJECT_CT_MAX);
>        if (FLOATP (Vgc_cons_percentage))
> 	{
> 	  double tot = (XFLOAT_DATA (Vgc_cons_percentage)
> 			* total_bytes_of_live_objects ());
> 	  if (threshold < tot)
> 	    {
> 	      if (tot < OBJECT_CT_MAX)
> 		threshold = tot;
> 	      else
> 		threshold = OBJECT_CT_MAX;
> 	    }
> 	}
>        consing_until_gc = threshold;
>      }
> 
> First, gc_cons_threshold is an EMACS_INT, so putting its value into
> intptr_t is wrong in 32-bit builds --with-wide-int, right?

That's not a problem, since the above code does min (..., OBJECT_CT_MAX) on the 
result before storing it into intptr_t.

> using intptr_t for OBJECT_CT_MAX is wrong in such a build.

I don't see why it's wrong. The idea is to count the total number of object 
bytes in use. This cannot exceed the number of bytes addressable by pointers 
regardless of the width of EMACS_INT, so intptr_t is appropriate for such counts.
> And second, why does the code divide gc_cons_threshold by 8?  If the
> value of gc_cons_threshold is most-positive-fixnum, that is wrong, I
> think.  Did you mean to divide GC_DEFAULT_THRESHOLD instead?

Right you are; that's a typo. Thanks. I fixed that in master in the attached patch.

--------------3A5BBA64323C417A2FD237A2
Content-Type: text/x-patch;
 name="0001-Fix-GC-threshold-typo.patch"
Content-Disposition: attachment;
 filename="0001-Fix-GC-threshold-typo.patch"
Content-Transfer-Encoding: quoted-printable

From 1e5bda273a67f960fb834007f4653a630cd67ce9 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@HIDDEN>
Date: Tue, 13 Aug 2019 10:03:41 -0700
Subject: [PATCH] Fix GC threshold typo
MIME-Version: 1.0
Content-Type: text/plain; charset=3DUTF-8
Content-Transfer-Encoding: 8bit

Problem reported by Eli Zaretskii (Bug#37006#25).
* src/alloc.c (garbage_collect_1): Fix typo in threshold calc.
Go back to dividing by 10 since the numerator=E2=80=99s a constant now.
Problem introduced in 2019-07-21T02:40:03Z!eggert@HIDDEN
---
 src/alloc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/alloc.c b/src/alloc.c
index 39833f8dec..c7419e2fa5 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -5932,8 +5932,8 @@ garbage_collect_1 (struct gcstat *gcst)
     consing_until_gc =3D memory_full_cons_threshold;
   else
     {
-      intptr_t threshold =3D min (max (GC_DEFAULT_THRESHOLD,
-				     gc_cons_threshold >> 3),
+      intptr_t threshold =3D min (max (GC_DEFAULT_THRESHOLD / 10,
+				     gc_cons_threshold),
 				OBJECT_CT_MAX);
       if (FLOATP (Vgc_cons_percentage))
 	{
--=20
2.17.1


--------------3A5BBA64323C417A2FD237A2--




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

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


Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 17:04:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 13 13:04:34 2019
Received: from localhost ([127.0.0.1]:48604 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hxaDp-0002Hp-If
	for submit <at> debbugs.gnu.org; Tue, 13 Aug 2019 13:04:33 -0400
Received: from eggs.gnu.org ([209.51.188.92]:49759)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hxaDn-0002HP-T4
 for 37006 <at> debbugs.gnu.org; Tue, 13 Aug 2019 13:04:32 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:41900)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hxaDi-0002mt-7s; Tue, 13 Aug 2019 13:04:26 -0400
Received: from [176.228.60.248] (port=2871 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hxaDh-0007Yl-L0; Tue, 13 Aug 2019 13:04:26 -0400
Date: Tue, 13 Aug 2019 20:04:13 +0300
Message-Id: <83ftm5ro8i.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= <mattiase@HIDDEN>
In-reply-to: <3E8F9821-8C8B-48AD-BC88-7191450C4D7E@HIDDEN> (message from
 Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Tue, 13 Aug 2019 18:48:05 +0200)
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
References: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
 <83h86nu0pq.fsf@HIDDEN> <86pnlbphus.fsf@HIDDEN>
 <83a7cft8qx.fsf@HIDDEN> <868srysb9x.fsf@HIDDEN>
 <83wofis508.fsf@HIDDEN> <A3B3F9F1-4ADD-4565-876C-24A3E4AABC7F@HIDDEN>
 <83h86lrs8p.fsf@HIDDEN> <3E8F9821-8C8B-48AD-BC88-7191450C4D7E@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 37006
Cc: jrm@HIDDEN, eggert@HIDDEN, 37006 <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 (---)

> From: Mattias Engdegård <mattiase@HIDDEN>
> Date: Tue, 13 Aug 2019 18:48:05 +0200
> Cc: jrm@HIDDEN, eggert@HIDDEN, 37006 <at> debbugs.gnu.org
> 
> > Yes, but the full calculation of the threshold is more complicated
> > than that.  For starters, how do you handle gc_cons_threshold values
> > that are smaller than GC_DEFAULT_THRESHOLD / 10 under your proposal?
> > There are use cases where the value was below that before and is above
> > now, or the other way around, or was below and stays below.
> 
> If a change to gc_cons_threshold has us end up in garbage_collect too soon, we can just adjust the bias and consing_until_gc and continue; the cost for doing so is small and amortised. Conversely, if the user raises gc_cons_threshold beyond the limit (OBJECT_CT_MAX), the intention is clearly to inhibit GC anyway.
> 
> > And that's even before we consider other complications: when
> > memory-full is non-nil, we should use a different threshold; and what
> > about user changes to gc-cons-percentage?
> 
> The check for memory-full was already eliminated from maybe_gc by changing consing_until_gc when that condition occurs, which seems reasonable enough. Regarding changes gc-cons-percentage, the effect will just be delayed to next GC --- is this really harmful?

IOW, you think that whatever this changes in user-facing behavior is
unimportant, and we shouldn't be bothered about it.  I happen to
disagree.

> I could be wrong about all this; I'm a bit confused by the threshold computation, too. However, Paul's consolidation of conditions in the hot and inlined maybe_gc makes eminently sense to me.

I cannot say the same thing myself, sorry.  Making a frequent
operation faster definitely makes sense, even if the speedup is minor.
But doing that and as result breaking use cases that worked for years,
or even just changing their effects in a tangible manner? what's our
excuse for that?




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

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


Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 16:48:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 13 12:48:25 2019
Received: from localhost ([127.0.0.1]:48600 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hxZyD-0001sh-2O
	for submit <at> debbugs.gnu.org; Tue, 13 Aug 2019 12:48:25 -0400
Received: from mail154c50.megamailservers.eu ([91.136.10.164]:55714
 helo=mail50c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1hxZy9-0001sV-LH
 for 37006 <at> debbugs.gnu.org; Tue, 13 Aug 2019 12:48:23 -0400
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1565714889;
 bh=pA9IrvZt+YxsYFEkJaBHP92ILrbaH2X9isYjgHDxpz8=;
 h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
 b=ONp6h4DByyXVDY5K1zqluKb2s+I+EoCdiiAdCJCON9pyXaiNuyHz88xxUy7CSddjU
 rn+051DVDzALK0kSlCqRDT7o0gk8tjrPB2CL0x5amAgFx3W+hO4cv1rIxXC1BICNpq
 XzvUlv7hhUqf22V2sNOCecLKvdUjrZCyNchcvu+w=
Feedback-ID: mattiase@HIDDEN
Received: from [192.168.0.4] ([188.150.171.71]) (authenticated bits=0)
 by mail50c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id x7DGm6wv022361; 
 Tue, 13 Aug 2019 16:48:07 +0000
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
In-Reply-To: <83h86lrs8p.fsf@HIDDEN>
Date: Tue, 13 Aug 2019 18:48:05 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E8F9821-8C8B-48AD-BC88-7191450C4D7E@HIDDEN>
References: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
 <83h86nu0pq.fsf@HIDDEN> <86pnlbphus.fsf@HIDDEN>
 <83a7cft8qx.fsf@HIDDEN> <868srysb9x.fsf@HIDDEN>
 <83wofis508.fsf@HIDDEN> <A3B3F9F1-4ADD-4565-876C-24A3E4AABC7F@HIDDEN>
 <83h86lrs8p.fsf@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.11)
X-CTCH-RefID: str=0001.0A0B020D.5D52E9C9.000E, ss=1, re=0.000, recu=0.000,
 reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.3 cv=CNcEoyjD c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117
 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19
 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=mDV3o1hIAAAA:8
 a=MSCd30SWwwHpbCGJnNgA:9 a=CjuIK1q_8ugA:10 a=_FVE-zBwftR9WsbkzFJk:22
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 37006
Cc: jrm@HIDDEN, eggert@HIDDEN, 37006 <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.7 (/)

13 aug. 2019 kl. 17.37 skrev Eli Zaretskii <eliz@HIDDEN>:
>=20
> Yes, but the full calculation of the threshold is more complicated
> than that.  For starters, how do you handle gc_cons_threshold values
> that are smaller than GC_DEFAULT_THRESHOLD / 10 under your proposal?
> There are use cases where the value was below that before and is above
> now, or the other way around, or was below and stays below.

If a change to gc_cons_threshold has us end up in garbage_collect too =
soon, we can just adjust the bias and consing_until_gc and continue; the =
cost for doing so is small and amortised. Conversely, if the user raises =
gc_cons_threshold beyond the limit (OBJECT_CT_MAX), the intention is =
clearly to inhibit GC anyway.

> And that's even before we consider other complications: when
> memory-full is non-nil, we should use a different threshold; and what
> about user changes to gc-cons-percentage?

The check for memory-full was already eliminated from maybe_gc by =
changing consing_until_gc when that condition occurs, which seems =
reasonable enough. Regarding changes gc-cons-percentage, the effect will =
just be delayed to next GC --- is this really harmful?

I could be wrong about all this; I'm a bit confused by the threshold =
computation, too. However, Paul's consolidation of conditions in the hot =
and inlined maybe_gc makes eminently sense to me.





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

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


Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 15:38:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 13 11:38:03 2019
Received: from localhost ([127.0.0.1]:48568 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hxYs7-0000Ay-3W
	for submit <at> debbugs.gnu.org; Tue, 13 Aug 2019 11:38:03 -0400
Received: from eggs.gnu.org ([209.51.188.92]:38579)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hxYs5-0000AI-DL
 for 37006 <at> debbugs.gnu.org; Tue, 13 Aug 2019 11:38:01 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:40273)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hxYrz-0003sj-J5; Tue, 13 Aug 2019 11:37:55 -0400
Received: from [176.228.60.248] (port=1323 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hxYry-0007pt-Vf; Tue, 13 Aug 2019 11:37:55 -0400
Date: Tue, 13 Aug 2019 18:37:42 +0300
Message-Id: <83h86lrs8p.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= <mattiase@HIDDEN>
In-reply-to: <A3B3F9F1-4ADD-4565-876C-24A3E4AABC7F@HIDDEN> (message from
 Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Mon, 12 Aug 2019 19:00:37 +0200)
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
References: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
 <83h86nu0pq.fsf@HIDDEN> <86pnlbphus.fsf@HIDDEN>
 <83a7cft8qx.fsf@HIDDEN> <868srysb9x.fsf@HIDDEN>
 <83wofis508.fsf@HIDDEN> <A3B3F9F1-4ADD-4565-876C-24A3E4AABC7F@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 37006
Cc: jrm@HIDDEN, eggert@HIDDEN, 37006 <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 (---)

> From: Mattias Engdegård <mattiase@HIDDEN>
> Date: Mon, 12 Aug 2019 19:00:37 +0200
> Cc: Joseph Mingrone <jrm@HIDDEN>, Paul Eggert <eggert@HIDDEN>,
>         37006 <at> debbugs.gnu.org
> 
> What about biasing consing_until_gc by gc_cons_threshold, and change the condition in maybe_gc to (the moral equivalent of)
> 
>  if (consing_until_gc < gc_cons_threshold)
> 
> ? It is practically as cheap as the current test against 0.

Yes, but the full calculation of the threshold is more complicated
than that.  For starters, how do you handle gc_cons_threshold values
that are smaller than GC_DEFAULT_THRESHOLD / 10 under your proposal?
There are use cases where the value was below that before and is above
now, or the other way around, or was below and stays below.

And that's even before we consider other complications: when
memory-full is non-nil, we should use a different threshold; and what
about user changes to gc-cons-percentage?




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

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


Received: (at 37006) by debbugs.gnu.org; 12 Aug 2019 17:01:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 12 13:01:00 2019
Received: from localhost ([127.0.0.1]:47351 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hxDgq-0004WP-KB
	for submit <at> debbugs.gnu.org; Mon, 12 Aug 2019 13:01:00 -0400
Received: from mail1430c50.megamailservers.eu ([91.136.14.30]:52804
 helo=mail118c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1hxDgn-0004WA-3h
 for 37006 <at> debbugs.gnu.org; Mon, 12 Aug 2019 13:00:58 -0400
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1565629241;
 bh=RmmUz9/rkFpHWAxAqJoDF0cKLygOB8LY2cy5UzEPbbk=;
 h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
 b=n5zb17kSghIDfV1WqHGl/96hqpBsAkp3kxnfUG6q8Gq7UgdEvgPmRzifF1LP6kamt
 0u4BbXj+IoKHlPuJVcf/jFJDmD3jykQbYimTYNGx/QpCIQJ1BQOXFo42S7DWBps+yi
 dbR1q+lK2xWXcqlpVDbnwi6+pu/2fh+K8gM485eo=
Feedback-ID: mattiase@HIDDEN
Received: from [192.168.0.4] ([188.150.171.71]) (authenticated bits=0)
 by mail118c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id x7CH0b1l019414; 
 Mon, 12 Aug 2019 17:00:39 +0000
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
In-Reply-To: <83wofis508.fsf@HIDDEN>
Date: Mon, 12 Aug 2019 19:00:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A3B3F9F1-4ADD-4565-876C-24A3E4AABC7F@HIDDEN>
References: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
 <83h86nu0pq.fsf@HIDDEN> <86pnlbphus.fsf@HIDDEN>
 <83a7cft8qx.fsf@HIDDEN> <868srysb9x.fsf@HIDDEN>
 <83wofis508.fsf@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.11)
X-CTCH-RefID: str=0001.0A0B0205.5D519B39.000C, ss=1, re=0.000, recu=0.000,
 reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.3 cv=Mqx8FVSe c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117
 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19
 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=mDV3o1hIAAAA:8
 a=MnNeRBu_eXT3IsHPgBoA:9 a=CjuIK1q_8ugA:10 a=_FVE-zBwftR9WsbkzFJk:22
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 37006
Cc: Joseph Mingrone <jrm@HIDDEN>, Paul Eggert <eggert@HIDDEN>,
 37006 <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.0 (/)

12 aug. 2019 kl. 18.49 skrev Eli Zaretskii <eliz@HIDDEN>:

> [...] We must
> have something in maybe_gc to notice the change and recompute the
> threshold.  We must also notice the memory-full condition there.

What about biasing consing_until_gc by gc_cons_threshold, and change the =
condition in maybe_gc to (the moral equivalent of)

 if (consing_until_gc < gc_cons_threshold)

? It is practically as cheap as the current test against 0.





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

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


Received: (at 37006) by debbugs.gnu.org; 12 Aug 2019 16:50:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 12 12:50:08 2019
Received: from localhost ([127.0.0.1]:47347 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hxDWK-0004F1-Cr
	for submit <at> debbugs.gnu.org; Mon, 12 Aug 2019 12:50:08 -0400
Received: from eggs.gnu.org ([209.51.188.92]:44493)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hxDWF-0004EO-M4
 for 37006 <at> debbugs.gnu.org; Mon, 12 Aug 2019 12:50:06 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:53015)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hxDW9-0003FP-KN; Mon, 12 Aug 2019 12:49:57 -0400
Received: from [176.228.60.248] (port=1033 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hxDW9-0003I2-1J; Mon, 12 Aug 2019 12:49:57 -0400
Date: Mon, 12 Aug 2019 19:49:43 +0300
Message-Id: <83wofis508.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Joseph Mingrone <jrm@HIDDEN>, Paul Eggert <eggert@HIDDEN>
In-reply-to: <868srysb9x.fsf@HIDDEN> (message from Joseph Mingrone on
 Mon, 12 Aug 2019 11:34:18 -0300)
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
References: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
 <83h86nu0pq.fsf@HIDDEN> <86pnlbphus.fsf@HIDDEN>
 <83a7cft8qx.fsf@HIDDEN> <868srysb9x.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 37006
Cc: mattiase@HIDDEN, 37006 <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 (---)

> From: Joseph Mingrone <jrm@HIDDEN>
> Cc: mattiase@HIDDEN,  eggert@HIDDEN,  37006 <at> debbugs.gnu.org
> Date: Mon, 12 Aug 2019 11:34:18 -0300
> 
> The fix did not initially work for me.  I tested a bit more.  With
> 
> 1. emacs -Q
> 2. (setq garbage-collection-messages t)
> 3. page through xdisp.c
> 
> I saw lots of garbage collection messages.  But, with my init.el there
> were no such messages.  My init.el looked like this.
> 
> ----------------------------------------------------
> (setq gc-cons-threshold most-positive-fixnum)
> 
> ;; contents of init.el here
> 
> (setq gc-cons-threshold 800000) ;; default value
> ----------------------------------------------------
> 
> When I removed the surrounding setqs, garbage collection message were
> shown again when paging through xdisp.c.
> 
> I assume that temporarily setting `gc-cons-threshold' to a large number
> to temporarily prevent garbage collection, then setting it back to a
> reasonable value should be acceptable.

Yes, of course.  There's a separate bug in the recent GC-related
changes.  Thanks for pointing this out.

Paul, the current method of updating consing_until_gc only in
garbage_collect_1 isn't workable, because it doesn't support the (very
popular nowadays) paradigm of temporarily setting gc-cons-threshold
very high: doing so avoids calling garbage_collect_1, and thus the
change of the threshold back to a lower value is never seen.  We must
have something in maybe_gc to notice the change and recompute the
threshold.  We must also notice the memory-full condition there.

We need to fix this ASAP, please.

I also don't think I understand the details of the threshold
calculations:

  if (!NILP (Vmemory_full))
    consing_until_gc = memory_full_cons_threshold;
  else
    {
      intptr_t threshold = min (max (GC_DEFAULT_THRESHOLD,
				     gc_cons_threshold >> 3),
				OBJECT_CT_MAX);
      if (FLOATP (Vgc_cons_percentage))
	{
	  double tot = (XFLOAT_DATA (Vgc_cons_percentage)
			* total_bytes_of_live_objects ());
	  if (threshold < tot)
	    {
	      if (tot < OBJECT_CT_MAX)
		threshold = tot;
	      else
		threshold = OBJECT_CT_MAX;
	    }
	}
      consing_until_gc = threshold;
    }

First, gc_cons_threshold is an EMACS_INT, so putting its value into
intptr_t is wrong in 32-bit builds --with-wide-int, right?  For the
same reason, using intptr_t for OBJECT_CT_MAX is wrong in such a
build.

And second, why does the code divide gc_cons_threshold by 8?  If the
value of gc_cons_threshold is most-positive-fixnum, that is wrong, I
think.  Did you mean to divide GC_DEFAULT_THRESHOLD instead?




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

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


Received: (at 37006) by debbugs.gnu.org; 12 Aug 2019 14:34:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 12 10:34:30 2019
Received: from localhost ([127.0.0.1]:47288 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hxBP3-0000wU-UN
	for submit <at> debbugs.gnu.org; Mon, 12 Aug 2019 10:34:30 -0400
Received: from mail-qt1-f169.google.com ([209.85.160.169]:35106)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <jrm@HIDDEN>) id 1hxBP1-0000wG-AG
 for 37006 <at> debbugs.gnu.org; Mon, 12 Aug 2019 10:34:27 -0400
Received: by mail-qt1-f169.google.com with SMTP id u34so3688518qte.2
 for <37006 <at> debbugs.gnu.org>; Mon, 12 Aug 2019 07:34:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftfl.ca; s=google;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version;
 bh=Y6r/owwUTf9wjADm6W92GeOotxDw+6CboKF7B1mFarA=;
 b=NbFGwRzMTvd6V6gysPSt3zLv14dzNKW6QqRR0B5sC1nvFo0vIwDVx3CqqWKRVB3fN4
 RLC+N92abDMegyH05QKc9vrIB8g0hnaPzkp/kIFJCbD3Ujf8/6nsZXpqhe8xDTblvZh+
 vBryT4NpjMUF0+KfvPEv2l4+cvfzUqzU2QOjM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version;
 bh=Y6r/owwUTf9wjADm6W92GeOotxDw+6CboKF7B1mFarA=;
 b=ZzWJ36U3JkiDqgYmQyH422R8BPJHlSpHCU13KnSZQmv/Dix6azbkEtqI2YD15h6z9w
 9aZlABgsX2FVHq9yJdRCmh6V8w9lrMG7mqGrYbZrOci+HyyXGJOUIv4LTujnYXGSKs5+
 D/zgRMPwmAWE2ST7U1E1nZhiEsrWAewvZdfrj2BbYN6yzSj9udGWfV03DeN2spD7F4zv
 uurHBPygO1BuPR390Fc420XB6rp4AQDUP7hUuuoFhEPBmh+li4LQCM2YXvBYoPoa1IQg
 az1DpPTx5RMMPy7YduXiwkNg5BvWyGgMmj/mjWRpOsbMxRssS6o/96ErvXSC4Xs/B3RA
 xbfQ==
X-Gm-Message-State: APjAAAU0BX0x21ooJ8B0c437xgC5W96sevTq+sCdmZiqgHeYDEDFulhP
 dWhjVRx12T4Nr1jKYTbftnjqbOJ4ygU=
X-Google-Smtp-Source: APXvYqziAG+2GufOhHlGOY5IeFaEYTWQbCzw1snapU3GpyjDZSh6KWMezU07Kx1FMHM1nTneYxbJHQ==
X-Received: by 2002:ac8:67c7:: with SMTP id r7mr6008039qtp.78.1565620461280;
 Mon, 12 Aug 2019 07:34:21 -0700 (PDT)
Received: from phe.ftfl.ca.ftfl.ca
 (drmons0544w-142-167-140-18.dhcp-dynamic.fibreop.ns.bellaliant.net.
 [142.167.140.18])
 by smtp.gmail.com with ESMTPSA id t76sm48169295qke.79.2019.08.12.07.34.19
 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256);
 Mon, 12 Aug 2019 07:34:19 -0700 (PDT)
From: Joseph Mingrone <jrm@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
References: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
 <83h86nu0pq.fsf@HIDDEN> <86pnlbphus.fsf@HIDDEN>
 <83a7cft8qx.fsf@HIDDEN>
Date: Mon, 12 Aug 2019 11:34:18 -0300
In-Reply-To: <83a7cft8qx.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 12 Aug
 2019 05:31:18 +0300")
Message-ID: <868srysb9x.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (berkeley-unix)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 37006
Cc: mattiase@HIDDEN, eggert@HIDDEN, 37006 <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 (-)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Joseph Mingrone <jrm@HIDDEN>
>> Cc: Mattias Engdeg=C3=A5rd <mattiase@HIDDEN>,
>>   eggert@HIDDEN
>> Date: Sun, 11 Aug 2019 17:28:11 -0300

>> > Thanks, I fixed this slightly differently, in a way that makes it more
>> > explicit why we need a non-trivial code there.  Joseph, please see if
>> > the latest master fixes the problem.

>> > (IMNSHO, this issue makes INT_ADD_WRAPV and friends unsafe; at the
>> > very least this caveat should be prominently documented in Gnulib's
>> > intprops.h.)

>> I have been running 94644d8 for the past hour or so and resident
>> memory for the Emacs process is up over 1300 MB.  Also with
>> `garbage-collection-messages' set to t, I do not see any messages
>> about garbage collection.

> Are you saying that the fix didn't solve the problem for you?  I
> definitely saw a lot of GC messages after the fix where I didn't
> before.  For example, if you visit xdisp.c from the Emacs sources and
> page through it with C-v, don't you see a lot of GC messages?

>> I should also add that after my initial report, running 26de2d42, I
>> did eventually start seeing garbage collection messages and the
>> memory usage stopped increasing.  Something must have triggered
>> garbage collection to start again.

> After a lot of consing, the GC would come back for a while, until it
> would be effectively disabled again by some opportune code path.

> If you see no GC messages for a long time, attach a debugger and look
> at the value of consing_until_gc.  If its value is huge, around
> LONG_MAX, the problem is still not completely solved.

The fix did not initially work for me.  I tested a bit more.  With

1. emacs -Q
2. (setq garbage-collection-messages t)
3. page through xdisp.c

I saw lots of garbage collection messages.  But, with my init.el there
were no such messages.  My init.el looked like this.

=2D---------------------------------------------------
(setq gc-cons-threshold most-positive-fixnum)

;; contents of init.el here

(setq gc-cons-threshold 800000) ;; default value
=2D---------------------------------------------------

When I removed the surrounding setqs, garbage collection message were
shown again when paging through xdisp.c.

I assume that temporarily setting `gc-cons-threshold' to a large number
to temporarily prevent garbage collection, then setting it back to a
reasonable value should be acceptable.  Help for `gc-cons-threshold'
says

      By binding this temporarily to a large number, you can effectively
      prevent garbage collection during a part of the program.

=2D-
Joseph

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQKgBAEBCgCKFiEEVbCTpybDiFVxIrrVNqQMg7DW754FAl1ReOpfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU1
QjA5M0E3MjZDMzg4NTU3MTIyQkFENTM2QTQwQzgzQjBENkVGOUUMHGpybUBmdGZs
LmNhAAoJEDakDIOw1u+eZIoP/jUm0zVwfFetu294y55U04IEmr/pZlu6+vDmIW75
rK+bm2SCVspM/ioh2VB0pvQK8WY0UKuNMkj2p028Y9RGzUQ82AQxRK7b+UiF5d41
2Zj7fDuIKc+FQeXzgdfUNn11Iy4Y4TlWHbZVn9A9qZuafaZ4SlWmjoZ/Vp/r8n2A
Dkqk0jUlZQw414FW/fk1zf7Bu1vz2UL+Un+EaaoLaDPofAGjXdZJKPh+Des5452M
blLBufoAX2+upg0T89RjTPhcms2st4Lf30QVuOsW+bvB5/3+8vRN5fH1l4usYSgL
1UQaqrp1H8LBMhpqI12abIs4tSBfuk4fj7YBsvogM0X6hhOfwGFKFNYCTBaZorUy
mCkvaYdI+xAMS2AYnHUrKEzeCSchuUS5yxp4BpQZn4+q/G6OXHyBtL52e9GDI4Vk
zPzw9JzRYPFG3R6k6QVG1JVExRzw9fOKr4N+GHPA5bTpA1/wFtbiAOfIe9E1XH+v
nH9TUXr0AtCgR1NyZan45Cn6o0vIrriHVGSBgcvItGayDM6NXSZNji0Rf0aaEwDA
zFoBjr6PBoaZec0bO8q1Q4q0pPxPqEegARROesjRM3MjxvmzTmHlCNE12lW3BrHo
FkCLh5U3RVAX+2QXB+rqJcZDkkieziwJqfg/AhgQ9jCew30qCym7E9jWqpIkbSZC
LUL4
=xDb9
-----END PGP SIGNATURE-----
--=-=-=--




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

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


Received: (at 37006) by debbugs.gnu.org; 12 Aug 2019 02:31:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 11 22:31:44 2019
Received: from localhost ([127.0.0.1]:46003 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hx07b-0000R0-QV
	for submit <at> debbugs.gnu.org; Sun, 11 Aug 2019 22:31:44 -0400
Received: from eggs.gnu.org ([209.51.188.92]:48358)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hx07Z-0000Kq-Lg
 for 37006 <at> debbugs.gnu.org; Sun, 11 Aug 2019 22:31:42 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:43609)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hx07T-0004R8-HS; Sun, 11 Aug 2019 22:31:35 -0400
Received: from [176.228.60.248] (port=4439 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hx07S-0000TZ-Cq; Sun, 11 Aug 2019 22:31:35 -0400
Date: Mon, 12 Aug 2019 05:31:18 +0300
Message-Id: <83a7cft8qx.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Joseph Mingrone <jrm@HIDDEN>
In-reply-to: <86pnlbphus.fsf@HIDDEN> (message from Joseph Mingrone on
 Sun, 11 Aug 2019 17:28:11 -0300)
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
References: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
 <83h86nu0pq.fsf@HIDDEN> <86pnlbphus.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 37006
Cc: mattiase@HIDDEN, eggert@HIDDEN, 37006 <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 (---)

> From: Joseph Mingrone <jrm@HIDDEN>
> Cc: Mattias Engdegård <mattiase@HIDDEN>,
>   eggert@HIDDEN
> Date: Sun, 11 Aug 2019 17:28:11 -0300
> 
> > Thanks, I fixed this slightly differently, in a way that makes it more
> > explicit why we need a non-trivial code there.  Joseph, please see if
> > the latest master fixes the problem.
> 
> > (IMNSHO, this issue makes INT_ADD_WRAPV and friends unsafe; at the
> > very least this caveat should be prominently documented in Gnulib's
> > intprops.h.)
> 
> I have been running 94644d8 for the past hour or so and resident memory for the Emacs process is up over 1300 MB.  Also with `garbage-collection-messages' set to t, I do not see any messages about garbage collection.

Are you saying that the fix didn't solve the problem for you?  I
definitely saw a lot of GC messages after the fix where I didn't
before.  For example, if you visit xdisp.c from the Emacs sources and
page through it with C-v, don't you see a lot of GC messages?

> I should also add that after my initial report, running 26de2d42, I did eventually start seeing garbage collection messages and the memory usage stopped increasing.  Something must have triggered garbage collection to start again.

After a lot of consing, the GC would come back for a while, until it
would be effectively disabled again by some opportune code path.

If you see no GC messages for a long time, attach a debugger and look
at the value of consing_until_gc.  If its value is huge, around
LONG_MAX, the problem is still not completely solved.




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

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


Received: (at 37006) by debbugs.gnu.org; 11 Aug 2019 17:07:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 11 13:07:39 2019
Received: from localhost ([127.0.0.1]:45752 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hwrJj-0003jj-A0
	for submit <at> debbugs.gnu.org; Sun, 11 Aug 2019 13:07:39 -0400
Received: from eggs.gnu.org ([209.51.188.92]:45851)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hwrJi-0003jV-2Z
 for 37006 <at> debbugs.gnu.org; Sun, 11 Aug 2019 13:07:38 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:37036)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hwrJc-0004uM-9C; Sun, 11 Aug 2019 13:07:32 -0400
Received: from [176.228.60.248] (port=2026 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hwrJb-0001Nn-N9; Sun, 11 Aug 2019 13:07:32 -0400
Date: Sun, 11 Aug 2019 20:07:15 +0300
Message-Id: <83ftm7tyv0.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= <mattiase@HIDDEN>
In-reply-to: <24BB9DB5-D832-462F-A03C-5595A80B6973@HIDDEN> (message from
 Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Sun, 11 Aug 2019 18:23:28 +0200)
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
References: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
 <24BB9DB5-D832-462F-A03C-5595A80B6973@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 37006
Cc: jrm@HIDDEN, eggert@HIDDEN, 37006 <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 (---)

> From: Mattias Engdegård <mattiase@HIDDEN>
> Date: Sun, 11 Aug 2019 18:23:28 +0200
> Cc: Eli Zaretskii <eliz@HIDDEN>, Paul Eggert <eggert@HIDDEN>,
>         37006 <at> debbugs.gnu.org
> 
> Observed on macOS as well. Reason: free_cons has the condition
> 
>  if (INT_ADD_WRAPV (consing_until_gc, sizeof *ptr, &consing_until_gc))
> 
> which will return true (overflow) if consing_until_gc is negative, which is kind of defensible since sizeof is unsigned which causes the sum (consing_until_gc + sizeof *ptr) to be a large unsigned number that doesn't fit into consing_until_gc.
> 
> Clang 10 defines __GNUC__ to 4 which causes intprops.h to not use __builtin_add_overflow despite that being present and working.
> 
> Casting the sizeof should fix it; patch attached.

I believe it should be fixed now.




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

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


Received: (at 37006) by debbugs.gnu.org; 11 Aug 2019 16:23:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 11 12:23:43 2019
Received: from localhost ([127.0.0.1]:45736 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hwqdD-0000Ud-52
	for submit <at> debbugs.gnu.org; Sun, 11 Aug 2019 12:23:43 -0400
Received: from mail156c50.megamailservers.eu ([91.136.10.166]:46262
 helo=mail51c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1hwqdB-0000UV-N1
 for 37006 <at> debbugs.gnu.org; Sun, 11 Aug 2019 12:23:42 -0400
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1565540611;
 bh=8lBi61DL1i2QCkL+4PbqXBm9yFM3/3IKMkfdPftxsSQ=;
 h=From:Subject:Date:In-Reply-To:Cc:To:References:From;
 b=SFzWWBnhLOi50gecypJJQFHKuEckQiI+p6LxNVPXXG0UvOxvA0np33bWJMA7cmluH
 TSriDbwu8qwSSATyKdqNPAk0JqylmNUG4jI1ODr0ucUzk733XCl1IRJHd+Uu8jtvCp
 s9J5iN+S2jMK9fcVNj9VJt3nFuYjVcQL7ibO1vnY=
Feedback-ID: mattiase@HIDDEN
Received: from [192.168.0.4] ([188.150.171.71]) (authenticated bits=0)
 by mail51c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id x7BGNTAJ018346; 
 Sun, 11 Aug 2019 16:23:30 +0000
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Message-Id: <24BB9DB5-D832-462F-A03C-5595A80B6973@HIDDEN>
Content-Type: multipart/mixed;
 boundary="Apple-Mail=_D6DABFC1-0A66-4D5C-82F0-60D31AF39C10"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
Date: Sun, 11 Aug 2019 18:23:28 +0200
In-Reply-To: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
To: jrm@HIDDEN
References: <5075406D-6DB8-4560-BB64-7198526FCF9F@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.11)
X-CTCH-RefID: str=0001.0A0B020B.5D504103.0024, ss=1, re=0.000, recu=0.000,
 reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.3 cv=U6m889ju c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117
 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19
 a=M51BFTxLslgA:10 a=WtjGUeIEe98SbmMuVg0A:9 a=AmAs7HYEYo2_7xvh:21
 a=i6Idrmfwgjngf_50:21 a=CjuIK1q_8ugA:10 a=kyAyQksBrJXqRUp9kFYA:9
 a=B2y7HmGcmWMA:10
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 37006
Cc: Eli Zaretskii <eliz@HIDDEN>, Paul Eggert <eggert@HIDDEN>,
 37006 <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.7 (/)


--Apple-Mail=_D6DABFC1-0A66-4D5C-82F0-60D31AF39C10
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Observed on macOS as well. Reason: free_cons has the condition

 if (INT_ADD_WRAPV (consing_until_gc, sizeof *ptr, &consing_until_gc))

which will return true (overflow) if consing_until_gc is negative, which =
is kind of defensible since sizeof is unsigned which causes the sum =
(consing_until_gc + sizeof *ptr) to be a large unsigned number that =
doesn't fit into consing_until_gc.

Clang 10 defines __GNUC__ to 4 which causes intprops.h to not use =
__builtin_add_overflow despite that being present and working.

Casting the sizeof should fix it; patch attached.


--Apple-Mail=_D6DABFC1-0A66-4D5C-82F0-60D31AF39C10
Content-Disposition: attachment;
	filename=0001-Avoid-unsigned-addend-in-overflow-check-bug-37006.patch
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="0001-Avoid-unsigned-addend-in-overflow-check-bug-37006.patch"
Content-Transfer-Encoding: quoted-printable

=46rom=20f733339714cab022cbbdea06148795d452b183fe=20Mon=20Sep=2017=20=
00:00:00=202001=0AFrom:=20=3D?UTF-8?q?Mattias=3D20Engdeg=3DC3=3DA5rd?=3D=20=
<mattiase@HIDDEN>=0ADate:=20Sun,=2011=20Aug=202019=2018:11:54=20+0200=0A=
Subject:=20[PATCH]=20Avoid=20unsigned=20addend=20in=20overflow=20check=20=
(bug#37006)=0A=0A*=20src/alloc.c=20(free_cons):=20Cast=20addend=20to=20=
avoid=20spurious=20overflow=20when=0Aconsing_until_gc=20is=20negative.=0A=
---=0A=20src/alloc.c=20|=203=20++-=0A=201=20file=20changed,=202=20=
insertions(+),=201=20deletion(-)=0A=0Adiff=20--git=20a/src/alloc.c=20=
b/src/alloc.c=0Aindex=205e089311a2..d416d32743=20100644=0A---=20=
a/src/alloc.c=0A+++=20b/src/alloc.c=0A@@=20-2542,7=20+2542,8=20@@=20=
free_cons=20(struct=20Lisp_Cons=20*ptr)=0A=20=20=20ptr->u.s.u.chain=20=3D=20=
cons_free_list;=0A=20=20=20ptr->u.s.car=20=3D=20dead_object=20();=0A=20=20=
=20cons_free_list=20=3D=20ptr;=0A-=20=20if=20(INT_ADD_WRAPV=20=
(consing_until_gc,=20sizeof=20*ptr,=20&consing_until_gc))=0A+=20=20if=20=
(INT_ADD_WRAPV=20(consing_until_gc,=20(object_ct)=20sizeof=20*ptr,=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
&consing_until_gc))=0A=20=20=20=20=20consing_until_gc=20=3D=20=
OBJECT_CT_MAX;=0A=20=20=20gcstat.total_free_conses++;=0A=20}=0A--=20=0A=
2.20.1=20(Apple=20Git-117)=0A=0A=

--Apple-Mail=_D6DABFC1-0A66-4D5C-82F0-60D31AF39C10--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#37006; Package emacs. Full text available.
Added tag(s) patch. Request was from Mattias Engdegård <mattiase@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

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


Received: (at 37006) by debbugs.gnu.org; 11 Aug 2019 15:13:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 11 11:13:33 2019
Received: from localhost ([127.0.0.1]:45704 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hwpXJ-0007Je-Ju
	for submit <at> debbugs.gnu.org; Sun, 11 Aug 2019 11:13:33 -0400
Received: from eggs.gnu.org ([209.51.188.92]:33828)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hwpXG-0007JP-G7
 for 37006 <at> debbugs.gnu.org; Sun, 11 Aug 2019 11:13:32 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:36054)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hwpXB-0000GE-9G; Sun, 11 Aug 2019 11:13:25 -0400
Received: from [176.228.60.248] (port=2786 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hwpXA-0003Rv-Fw; Sun, 11 Aug 2019 11:13:25 -0400
Date: Sun, 11 Aug 2019 18:13:07 +0300
Message-Id: <83k1bju458.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Joseph Mingrone <jrm@HIDDEN>
In-reply-to: <86pnlbooyp.fsf@HIDDEN> (message from Joseph Mingrone on
 Sun, 11 Aug 2019 09:39:58 -0300)
Subject: Re: bug#37006: 27.0.50;
 garbage collection not happening after 26de2d42
References: <86pnlbooyp.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 37006
Cc: 37006 <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 (---)

> From: Joseph Mingrone <jrm@HIDDEN>
> Date: Sun, 11 Aug 2019 09:39:58 -0300
> 
> After 26de2d42 from 2019-06-20, garbage collection is not happening and
> allocated memory continues to grow until
> 
> Aug 10 21:39:02 <kern.err> phe kernel: pid 73800 (emacs-27.0.50), uid
> 1001, was killed: out of swap space
> 
> and
> 
> Aug 10 21:39:07 <kern.crit> phe kernel: swap_pager_getswapspace(3):
> failed

I see this on GNU/Linux, but not on MS-Windows, FWIW.




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

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


Received: (at submit) by debbugs.gnu.org; 11 Aug 2019 12:40:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 11 08:40:14 2019
Received: from localhost ([127.0.0.1]:44818 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hwn8v-00038p-Em
	for submit <at> debbugs.gnu.org; Sun, 11 Aug 2019 08:40:14 -0400
Received: from lists.gnu.org ([209.51.188.17]:57077)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <jrm@HIDDEN>) id 1hwn8s-00038c-Bl
 for submit <at> debbugs.gnu.org; Sun, 11 Aug 2019 08:40:11 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:60864)
 by lists.gnu.org with esmtp (Exim 4.86_2)
 (envelope-from <jrm@HIDDEN>) id 1hwn8p-0007o6-FZ
 for bug-gnu-emacs@HIDDEN; Sun, 11 Aug 2019 08:40:10 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,URIBL_BLOCKED
 autolearn=disabled version=3.3.2
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <jrm@HIDDEN>) id 1hwn8m-0000ZK-By
 for bug-gnu-emacs@HIDDEN; Sun, 11 Aug 2019 08:40:07 -0400
Received: from mail-qt1-x82c.google.com ([2607:f8b0:4864:20::82c]:36717)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
 (Exim 4.71) (envelope-from <jrm@HIDDEN>) id 1hwn8m-0000YT-1k
 for bug-gnu-emacs@HIDDEN; Sun, 11 Aug 2019 08:40:04 -0400
Received: by mail-qt1-x82c.google.com with SMTP id z4so100364117qtc.3
 for <bug-gnu-emacs@HIDDEN>; Sun, 11 Aug 2019 05:40:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftfl.ca; s=google;
 h=from:to:subject:date:message-id:user-agent:mime-version;
 bh=fkNShc/A5RRDO8PJbUZW0PSwMjhympNgLFXJcy8igzI=;
 b=ByhJltx/u0wd+tHtFYBlF33C4VlFt9S5/xgjOF4+b27uZZpPlt4UHMMpp+Xc7r8xYX
 voyHEBJC8XmubI2PmmlvltMmVuI73EwI4AUTtimoUfi8UzJVEyaNGg8+VaRmNXsSXR9b
 xQawIxucAmmg/8Ni+3o2v6RIPuFy/XLz/Xk9Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:subject:date:message-id:user-agent
 :mime-version;
 bh=fkNShc/A5RRDO8PJbUZW0PSwMjhympNgLFXJcy8igzI=;
 b=a9q1/B3uqDrHs5A6Bn2wQ6aw+K8qVTCpLahApdai+0hfTyOlCqNacB20/EeCz1c2/n
 qYHNIMjp+N4FUHx1OclNPqh+Z0BxQ7SI8a4GiUBqQ7R+91ElLfijrR5YEjHQeE05BWqf
 4t++RzffhDIWN3oFlkhNnVlUOmuOpxdi9abBGGJbZIzEgx3WxhXI+s/dQ/NqWAQIhjy5
 n07l2HtKcf6K62GZiOUyg0BrNnZVhYpwztl7Rv5GEXy4oDAahan6i7T6GRiEdCRZBin0
 /Bp8zlhJcWJFjMrb8iaGwlYSGFQffcs0Sojm63UxbYeEipib7VwNW6z+afqNslPRjQxD
 WNcQ==
X-Gm-Message-State: APjAAAU+h0C9Xn3tnzeU71wtj6yTkoUC5ZR51RsMldklzhB7n4pzJCwK
 FLj0d8vks3b3D1g1JEvr12TbWf+PME0=
X-Google-Smtp-Source: APXvYqxS1EhL3mQPLPjlWZPRm2eHwUqReOR2BpQXtDWNGGbQkGxLGENe4VtXEWkIMqd5a/9bjTb6AA==
X-Received: by 2002:ac8:2535:: with SMTP id 50mr25702940qtm.373.1565527201535; 
 Sun, 11 Aug 2019 05:40:01 -0700 (PDT)
Received: from phe.ftfl.ca.ftfl.ca
 (drmons0544w-142-167-140-18.dhcp-dynamic.fibreop.ns.bellaliant.net.
 [142.167.140.18])
 by smtp.gmail.com with ESMTPSA id f12sm3795389qkm.18.2019.08.11.05.40.00
 for <bug-gnu-emacs@HIDDEN>
 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256);
 Sun, 11 Aug 2019 05:40:00 -0700 (PDT)
From: Joseph Mingrone <jrm@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 27.0.50; garbage collection not happening after 26de2d42
Date: Sun, 11 Aug 2019 09:39:58 -0300
Message-ID: <86pnlbooyp.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
 recognized.
X-Received-From: 2607:f8b0:4864:20::82c
X-Spam-Score: -1.4 (-)
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.4 (--)

After 26de2d42 from 2019-06-20, garbage collection is not happening and
allocated memory continues to grow until

Aug 10 21:39:02 <kern.err> phe kernel: pid 73800 (emacs-27.0.50), uid
1001, was killed: out of swap space

and

Aug 10 21:39:07 <kern.crit> phe kernel: swap_pager_getswapspace(3):
failed

In GNU Emacs 27.0.50 (build 1, amd64-portbld-freebsd12.0, GTK+ Version 3.24.10)
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description: 12.0-RELEASE-p9

Configured using:
 'configure --disable-build-details --localstatedir=/var --with-x
 --enable-acl --without-cairo --without-dbus --without-gconf --with-gif
 --with-gnutls --without-gsettings --with-x-toolkit=gtk3
 --without-harfbuzz --with-jpeg --with-json
 --with-file-notification=kqueue --with-lcms2 --with-m17n-flt
 --with-imagemagick --with-mailutils --with-modules --with-sound=oss
 --with-libotf --with-png --with-toolkit-scroll-bars --with-rsvg
 --with-threads --with-tiff --with-xft --with-xim --with-xml2 --with-xpm
 --without-xwidgets --x-libraries=/usr/local/lib
 --x-includes=/usr/local/include --prefix=/usr/local
 --mandir=/usr/local/man --disable-silent-rules
 --infodir=/usr/local/share/emacs/info/
 --build=amd64-portbld-freebsd12.0 'CFLAGS=-O2 -pipe
 -fstack-protector-strong -isystem /usr/local/include
 -fno-strict-aliasing ' 'CPPFLAGS=-isystem /usr/local/include' 'LDFLAGS=
 -fstack-protector-strong -L/usr/local/lib ''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GLIB NOTIFY KQUEUE ACL
GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 XDBE XIM MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_CA.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Message

Minor modes in effect:
  gnus-message-citation-mode: t
  erc-spelling-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-netsplit-mode: t
  erc-menu-mode: t
  erc-log-mode: t
  erc-list-mode: t
  erc-pcomplete-mode: t
  erc-button-mode: t
  erc-stamp-mode: t
  erc-autojoin-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  mml-mode: t
  shell-dirtrack-mode: t
  flyspell-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  which-key-mode: t
  show-paren-mode: t
  savehist-mode: t
  global-company-mode: t
  company-mode: t
  global-auto-revert-mode: t
  counsel-mode: t
  ivy-mode: t
  cl-old-struct-compat-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  visual-line-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
/home/jrm/.emacs.d/elpa/slime-20190724.1352/slime-autoloads hides /usr/local/share/emacs/27.0.50/site-lisp/slime/slime-autoloads
/home/jrm/.emacs.d/elpa/slime-20190724.1352/slime hides /usr/local/share/emacs/27.0.50/site-lisp/slime/slime
/home/jrm/.emacs.d/elpa/slime-20190724.1352/slime-tests hides /usr/local/share/emacs/27.0.50/site-lisp/slime/slime-tests
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-org hides /usr/local/share/emacs/27.0.50/lisp/org/ox-org
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-bibtex hides /usr/local/share/emacs/27.0.50/lisp/org/org-bibtex
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ruby hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ruby
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-table hides /usr/local/share/emacs/27.0.50/lisp/org/ob-table
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-awk hides /usr/local/share/emacs/27.0.50/lisp/org/ob-awk
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-element hides /usr/local/share/emacs/27.0.50/lisp/org/org-element
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ref hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ref
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-processing hides /usr/local/share/emacs/27.0.50/lisp/org/ob-processing
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ditaa hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ditaa
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-info hides /usr/local/share/emacs/27.0.50/lisp/org/org-info
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-md hides /usr/local/share/emacs/27.0.50/lisp/org/ox-md
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-colview hides /usr/local/share/emacs/27.0.50/lisp/org/org-colview
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-mhe hides /usr/local/share/emacs/27.0.50/lisp/org/org-mhe
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-python hides /usr/local/share/emacs/27.0.50/lisp/org/ob-python
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-shell hides /usr/local/share/emacs/27.0.50/lisp/org/ob-shell
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-ascii hides /usr/local/share/emacs/27.0.50/lisp/org/ox-ascii
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-lisp hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lisp
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-capture hides /usr/local/share/emacs/27.0.50/lisp/org/org-capture
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-js hides /usr/local/share/emacs/27.0.50/lisp/org/ob-js
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-src hides /usr/local/share/emacs/27.0.50/lisp/org/org-src
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-sass hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sass
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-footnote hides /usr/local/share/emacs/27.0.50/lisp/org/org-footnote
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-lob hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lob
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-gnus hides /usr/local/share/emacs/27.0.50/lisp/org/org-gnus
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-picolisp hides /usr/local/share/emacs/27.0.50/lisp/org/ob-picolisp
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-scheme hides /usr/local/share/emacs/27.0.50/lisp/org/ob-scheme
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-mobile hides /usr/local/share/emacs/27.0.50/lisp/org/org-mobile
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-latex hides /usr/local/share/emacs/27.0.50/lisp/org/ob-latex
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-crypt hides /usr/local/share/emacs/27.0.50/lisp/org/org-crypt
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-docview hides /usr/local/share/emacs/27.0.50/lisp/org/org-docview
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob hides /usr/local/share/emacs/27.0.50/lisp/org/ob
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-icalendar hides /usr/local/share/emacs/27.0.50/lisp/org/ox-icalendar
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-rmail hides /usr/local/share/emacs/27.0.50/lisp/org/org-rmail
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-publish hides /usr/local/share/emacs/27.0.50/lisp/org/ox-publish
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-sed hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sed
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-datetree hides /usr/local/share/emacs/27.0.50/lisp/org/org-datetree
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-protocol hides /usr/local/share/emacs/27.0.50/lisp/org/org-protocol
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-matlab hides /usr/local/share/emacs/27.0.50/lisp/org/ob-matlab
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-inlinetask hides /usr/local/share/emacs/27.0.50/lisp/org/org-inlinetask
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-shen hides /usr/local/share/emacs/27.0.50/lisp/org/ob-shen
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-core hides /usr/local/share/emacs/27.0.50/lisp/org/ob-core
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-entities hides /usr/local/share/emacs/27.0.50/lisp/org/org-entities
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ebnf hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ebnf
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-coq hides /usr/local/share/emacs/27.0.50/lisp/org/ob-coq
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-forth hides /usr/local/share/emacs/27.0.50/lisp/org/ob-forth
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox hides /usr/local/share/emacs/27.0.50/lisp/org/ox
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-hledger hides /usr/local/share/emacs/27.0.50/lisp/org/ob-hledger
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-abc hides /usr/local/share/emacs/27.0.50/lisp/org/ob-abc
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org hides /usr/local/share/emacs/27.0.50/lisp/org/org
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-archive hides /usr/local/share/emacs/27.0.50/lisp/org/org-archive
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-J hides /usr/local/share/emacs/27.0.50/lisp/org/ob-J
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-macs hides /usr/local/share/emacs/27.0.50/lisp/org/org-macs
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-version hides /usr/local/share/emacs/27.0.50/lisp/org/org-version
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-exp hides /usr/local/share/emacs/27.0.50/lisp/org/ob-exp
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-ctags hides /usr/local/share/emacs/27.0.50/lisp/org/org-ctags
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-java hides /usr/local/share/emacs/27.0.50/lisp/org/ob-java
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-sql hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sql
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-lint hides /usr/local/share/emacs/27.0.50/lisp/org/org-lint
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-keys hides /usr/local/share/emacs/27.0.50/lisp/org/ob-keys
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-eshell hides /usr/local/share/emacs/27.0.50/lisp/org/org-eshell
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-plantuml hides /usr/local/share/emacs/27.0.50/lisp/org/ob-plantuml
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ocaml hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ocaml
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-sqlite hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sqlite
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-list hides /usr/local/share/emacs/27.0.50/lisp/org/org-list
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-lua hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lua
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-C hides /usr/local/share/emacs/27.0.50/lisp/org/ob-C
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-habit hides /usr/local/share/emacs/27.0.50/lisp/org/org-habit
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-bbdb hides /usr/local/share/emacs/27.0.50/lisp/org/org-bbdb
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-lilypond hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lilypond
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-latex hides /usr/local/share/emacs/27.0.50/lisp/org/ox-latex
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-asymptote hides /usr/local/share/emacs/27.0.50/lisp/org/ob-asymptote
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-groovy hides /usr/local/share/emacs/27.0.50/lisp/org/ob-groovy
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-screen hides /usr/local/share/emacs/27.0.50/lisp/org/ob-screen
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-org hides /usr/local/share/emacs/27.0.50/lisp/org/ob-org
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-eww hides /usr/local/share/emacs/27.0.50/lisp/org/org-eww
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-octave hides /usr/local/share/emacs/27.0.50/lisp/org/ob-octave
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-vala hides /usr/local/share/emacs/27.0.50/lisp/org/ob-vala
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-indent hides /usr/local/share/emacs/27.0.50/lisp/org/org-indent
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-macro hides /usr/local/share/emacs/27.0.50/lisp/org/org-macro
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-gnuplot hides /usr/local/share/emacs/27.0.50/lisp/org/ob-gnuplot
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-haskell hides /usr/local/share/emacs/27.0.50/lisp/org/ob-haskell
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-dot hides /usr/local/share/emacs/27.0.50/lisp/org/ob-dot
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-html hides /usr/local/share/emacs/27.0.50/lisp/org/ox-html
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-calc hides /usr/local/share/emacs/27.0.50/lisp/org/ob-calc
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-fortran hides /usr/local/share/emacs/27.0.50/lisp/org/ob-fortran
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-stan hides /usr/local/share/emacs/27.0.50/lisp/org/ob-stan
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ledger hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ledger
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-io hides /usr/local/share/emacs/27.0.50/lisp/org/ob-io
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-install hides /usr/local/share/emacs/27.0.50/lisp/org/org-install
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-clock hides /usr/local/share/emacs/27.0.50/lisp/org/org-clock
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-agenda hides /usr/local/share/emacs/27.0.50/lisp/org/org-agenda
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-table hides /usr/local/share/emacs/27.0.50/lisp/org/org-table
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-attach hides /usr/local/share/emacs/27.0.50/lisp/org/org-attach
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-faces hides /usr/local/share/emacs/27.0.50/lisp/org/org-faces
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-beamer hides /usr/local/share/emacs/27.0.50/lisp/org/ox-beamer
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-comint hides /usr/local/share/emacs/27.0.50/lisp/org/ob-comint
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-mscgen hides /usr/local/share/emacs/27.0.50/lisp/org/ob-mscgen
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-w3m hides /usr/local/share/emacs/27.0.50/lisp/org/org-w3m
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-maxima hides /usr/local/share/emacs/27.0.50/lisp/org/ob-maxima
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-css hides /usr/local/share/emacs/27.0.50/lisp/org/ob-css
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-compat hides /usr/local/share/emacs/27.0.50/lisp/org/org-compat
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-feed hides /usr/local/share/emacs/27.0.50/lisp/org/org-feed
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-irc hides /usr/local/share/emacs/27.0.50/lisp/org/org-irc
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-clojure hides /usr/local/share/emacs/27.0.50/lisp/org/ob-clojure
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-odt hides /usr/local/share/emacs/27.0.50/lisp/org/ox-odt
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-man hides /usr/local/share/emacs/27.0.50/lisp/org/ox-man
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-emacs-lisp hides /usr/local/share/emacs/27.0.50/lisp/org/ob-emacs-lisp
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-tangle hides /usr/local/share/emacs/27.0.50/lisp/org/ob-tangle
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-R hides /usr/local/share/emacs/27.0.50/lisp/org/ob-R
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-makefile hides /usr/local/share/emacs/27.0.50/lisp/org/ob-makefile
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-duration hides /usr/local/share/emacs/27.0.50/lisp/org/org-duration
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-texinfo hides /usr/local/share/emacs/27.0.50/lisp/org/ox-texinfo
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-id hides /usr/local/share/emacs/27.0.50/lisp/org/org-id
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-eval hides /usr/local/share/emacs/27.0.50/lisp/org/ob-eval
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-timer hides /usr/local/share/emacs/27.0.50/lisp/org/org-timer
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-mouse hides /usr/local/share/emacs/27.0.50/lisp/org/org-mouse
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-pcomplete hides /usr/local/share/emacs/27.0.50/lisp/org/org-pcomplete
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-loaddefs hides /usr/local/share/emacs/27.0.50/lisp/org/org-loaddefs
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-plot hides /usr/local/share/emacs/27.0.50/lisp/org/org-plot
/home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-perl hides /usr/local/share/emacs/27.0.50/lisp/org/ob-perl
/home/jrm/.emacs.d/elpa/let-alist-1.0.6/let-alist hides /usr/local/share/emacs/27.0.50/lisp/emacs-lisp/let-alist

Features:
(shadow emacsbug bbdb-message sendmail nnir bbdb-mua bbdb-com crm sort
gnus-cite mail-extr gnus-async gnus-bcklg qp gnus-ml disp-table
ace-window cl-print help-fns radix-tree make-mode tramp-cache tramp-sh
bookmark mm-archive mule-util url-http url-gw url-cache url-auth url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util finder-inf gnutls network-stream nsm erc-spelling
erc-ring erc-networks erc-netsplit erc-menu erc-log erc-list
erc-pcomplete erc-button erc-fill erc-stamp erc-join znc warnings
erc-track erc-match erc-tex easy-mmode erc-goodies erc erc-backend
erc-compat pp erc-loaddefs cl hl-line gnus-topic nndraft nnmh nnagent
nnml gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg
gnus-art mm-uu mml2015 mm-view mml-smime smime dig mailcap nntp
gnus-cache gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap
nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message
rmc puny rfc822 mml mml-sec epa derived epg mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader gnus-win
gnus nnheader wid-edit gnus-util rmail rmail-loaddefs rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils text-property-search time-date
tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat
shell pcomplete parse-time ls-lisp format-spec rx server flyspell ispell
undo-tree diff smart-mode-line-dark-theme smart-mode-line rich-minority
s pdf-tools-loaddefs misc hydra lv ace-link avy bbdb bbdb-site timezone
company-oddmuse company-keywords company-etags etags fileloop generator
company-gtags company-dabbrev-code company-dabbrev company-files
company-capf company-cmake company-xcode company-clang company-semantic
company-eclim company-template company-bbdb which-key paren savehist
company edmacro kmacro pcase autorevert filenotify counsel xdg xref
project dired dired-loaddefs compile comint ansi-color swiper cl-extra
help-mode ivy delsel ring colir color ivy-overlay ffap thingatpt
cus-start cus-load benchmark-init benchmark-init-loaddefs tex-site
advice slime-autoloads info package easymenu epg-config url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads kqueue lcms2 dynamic-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 4672710 1249112)
 (symbols 48 33763 2)
 (strings 32 177500 153301)
 (string-bytes 1 6559318)
 (vectors 16 108474)
 (vector-slots 8 4931122 2331820)
 (floats 8 565 3210)
 (intervals 56 12670 13121)
 (buffers 992 90))
<#secure method=pgpmime mode=sign>




Acknowledgement sent to Joseph Mingrone <jrm@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#37006; 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: Thu, 15 Aug 2019 01:45:02 UTC

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