From unknown Tue Jun 24 10:31:35 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#56793 <56793@debbugs.gnu.org> To: bug#56793 <56793@debbugs.gnu.org> Subject: Status: Infinite loop in pure_alloc when dumping strings longer than 10K bytes Reply-To: bug#56793 <56793@debbugs.gnu.org> Date: Tue, 24 Jun 2025 17:31:35 +0000 retitle 56793 Infinite loop in pure_alloc when dumping strings longer than = 10K bytes reassign 56793 emacs submitter 56793 Lynn Winebarger severity 56793 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 27 09:49:42 2022 Received: (at submit) by debbugs.gnu.org; 27 Jul 2022 13:49:42 +0000 Received: from localhost ([127.0.0.1]:55389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGhPx-0004GI-Ts for submit@debbugs.gnu.org; Wed, 27 Jul 2022 09:49:42 -0400 Received: from lists.gnu.org ([209.51.188.17]:54376) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGhPs-0004G3-AT for submit@debbugs.gnu.org; Wed, 27 Jul 2022 09:49:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40854) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGhPm-0004ow-NU for bug-gnu-emacs@gnu.org; Wed, 27 Jul 2022 09:49:36 -0400 Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]:55885) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oGhPk-0005s4-LP for bug-gnu-emacs@gnu.org; Wed, 27 Jul 2022 09:49:30 -0400 Received: by mail-pj1-x1030.google.com with SMTP id b10so16437498pjq.5 for ; Wed, 27 Jul 2022 06:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=RV7X4lj+2xsb7/6HiqkSJ8Jg/Dlqwp7jHmiUdUgJPuI=; b=FniHQ47xe/4WWTTVs+ipL9R/zUZqNS9XHJyCxn4w+9eR+RGWd/HvsfEyzOFt5mcnqG kQQj/Kbhe9T7saemaVbu5xah6KDtdWjgk9/H3+Nm8k/AKtvXdYlYege0C1/JNvmFFetj 8Lv+hwFYEPzsBSi5xhTXhDGS0tD/qTpXbR827OGShPUxSPdj00RsftfHKWLCNj9I3uhr zhZuRMPDkk0bCLQAz/OpkzXPByfyz6Nbl4k2iza9WpLgV4gorxAG712bsBqdXqE9mMAb x1a2KYfiI27GjU3iE8yJhD1OWLgsaYx7xhnQ98M9nh4465NhEzkl5Tm1TpnQ5ZRpwWK8 rYgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RV7X4lj+2xsb7/6HiqkSJ8Jg/Dlqwp7jHmiUdUgJPuI=; b=k++5ihJlE15Y70gjcgz9khZB5f39ObdIygIfxox/HkJGxw9AFWbNycY+fKQYnY58iR RpKD3EpUh/OyighKdFnPtAymuE44jygqgRnEoPhi7qVeCytVW1sGa5toK+EHyug2jPuP 08Xcj2l5Z1Syb1NVtSo6iiE/EFoakOtSPSzjmAxxLh/4F496gnwDthkj6oIUnsDIVGmy S8kFAO0cVwFg/6UnNoYA/xJkwtaDGkWvk0eXDcoT4TTL8/bTAl8PBYt+KAYRJDyGtzSp 8CCT41abuSOBFRYL9TaUNZatfVAulOrUiLxuohvcxijBAY7Eyz718OO6juYrCq8zUy4C cjYg== X-Gm-Message-State: AJIora+2EKRFvTZxrvHtIiaLwcOhLU91yhA4zWMgA+YtP1uysnXgFt8y +tiM+pSf0ML6LMpXUMpI47+be1LIx6ZkDTtPKP/1XpFVctE= X-Google-Smtp-Source: AGRyM1t1nwR7tlRcVIBmUUiMS0vzXiB+u3vK4HpQ9qIdL/c3qGstmfDdqoTGgnxJPQ2tXfkdUFg4rTxehipIlZrTmWQ= X-Received: by 2002:a17:903:260f:b0:16d:bafc:86c with SMTP id jd15-20020a170903260f00b0016dbafc086cmr1131189plb.121.1658929766087; Wed, 27 Jul 2022 06:49:26 -0700 (PDT) MIME-Version: 1.0 From: Lynn Winebarger Date: Wed, 27 Jul 2022 09:49:13 -0400 Message-ID: Subject: Infinite loop in pure_alloc when dumping strings longer than 10K bytes To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="0000000000006a416105e4c9af49" Received-SPF: pass client-ip=2607:f8b0:4864:20::1030; envelope-from=owinebar@gmail.com; helo=mail-pj1-x1030.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --0000000000006a416105e4c9af49 Content-Type: text/plain; charset="UTF-8" I apologize for not being able to include significant details of the build, as this is happening on a sandboxed system in a proprietary context. I've been attempting to dump emacs built from the 28.1 tarball with a large number of core libraries preloaded. I have observed runaway allocation when attempting to dump with native-compilation enabled and with native-compilation disabled. Using gdb I was able to identify the culprit as an infinite "goto again" loop in pure_alloc: static void * pure_alloc (size_t size, int type) { void *result; again: if (type >= 0) { /* Allocate space for a Lisp object from the beginning of the free space with taking account of alignment. */ result = pointer_align (purebeg + pure_bytes_used_lisp, LISP_ALIGNMENT); pure_bytes_used_lisp = ((char *)result - (char *)purebeg) + size; } else { /* Allocate space for a non-Lisp object from the end of the free space. */ ptrdiff_t unaligned_non_lisp = pure_bytes_used_non_lisp + size; char *unaligned = purebeg + pure_size - unaligned_non_lisp; int decr = (intptr_t) unaligned & (-1 - type); pure_bytes_used_non_lisp = unaligned_non_lisp + decr; result = unaligned - decr; } pure_bytes_used = pure_bytes_used_lisp + pure_bytes_used_non_lisp; if (pure_bytes_used <= pure_size) return result; /* Don't allocate a large amount here, because it might get mmap'd and then its address might not be usable. */ int small_amount = 10000; eassert (size <= small_amount - LISP_ALIGNMENT); purebeg = xzalloc (small_amount); pure_size = small_amount; pure_bytes_used_before_overflow += pure_bytes_used - size; pure_bytes_used = 0; pure_bytes_used_lisp = pure_bytes_used_non_lisp = 0; /* Can't GC if pure storage overflowed because we can't determine if something is a pure object or not. */ garbage_collection_inhibited++; goto again; } For example, the issue was triggered while attempting to dump ibuffer.el - a docstring has 10,655 characters, and the "eassert" is turned off with the usual CFLAGS, so it just never stops attempting to allocate. Since unexec is disabled, I don't even understand why avoiding mmap'ed memory is important. Pure space is just going to be copied into the cold storage area of the pdmp file anyway, no? In any case, changing the small amount to 20000 made the issue go away for the purpose of testing, but I'm not sure why there isn't some comparison of the size of the object to the small amount in the logic - either determining the minimum to allocate in one chunk, or attempting to obtain a contiguous chunk by successive xzallocs until the required size is obtained. Lynn --0000000000006a416105e4c9af49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I apologize for not being able to include significant deta= ils of the build, as this is happening on a sandboxed system in a proprieta= ry context.
I've been attempting to dump emacs built from the 28.1 t= arball with a large number of core libraries preloaded.=C2=A0 I have observ= ed runaway allocation when attempting to dump with native-compilation enabl= ed and with native-compilation disabled. =C2=A0
Using gdb I was able to = identify the culprit as an infinite "goto again" loop in pure_all= oc:
stat= ic void *
pure_alloc (size_t size, int type)
{
void *result;
ag= ain:
if (type >=3D 0)
{
/* Allocate space for a Lisp object fro= m the beginning of the free
space with taking account of alignment. */result =3D pointer_align (purebeg + pure_bytes_used_lisp, LISP_ALIGNMENT)= ;
pure_bytes_used_lisp =3D ((char *)result - (char *)purebeg) + size;}
else
{

/* Allocate space for a non-Lisp object from the end o= f the free
space. */
ptrdiff_t unaligned_non_lisp =3D pure_bytes_used= _non_lisp + size;
char *unaligned =3D purebeg + pure_size - unaligned_no= n_lisp;
int decr =3D (intptr_t) unaligned & (-1 - type);
pure_byt= es_used_non_lisp =3D unaligned_non_lisp + decr;
result =3D unaligned - d= ecr;
}
pure_bytes_used =3D pure_bytes_used_lisp + pure_bytes_used_non= _lisp;
if (pure_bytes_used <=3D pure_size)
return result;
/* Do= n't allocate a large amount here,
because it might get mmap'd an= d then its address
might not be usable. */
int small_amount =3D 10000= ;
eassert (size <=3D small_amount - LISP_ALIGNMENT);
purebeg =3D x= zalloc (small_amount);
pure_size =3D small_amount;
pure_bytes_used_be= fore_overflow +=3D pure_bytes_used - size;
pure_bytes_used =3D 0;
pur= e_bytes_used_lisp =3D pure_bytes_used_non_lisp =3D 0;
/* Can't GC if= pure storage overflowed because we can't determine
if something is = a pure object or not. */
garbage_collection_inhibited++;
goto again;<= br>}
For example, the issue was triggered while attempting to d= ump ibuffer.el=C2=A0 - a docstring has 10,655 characters, and the "eas= sert" is turned off with the usual CFLAGS, so it just never stops atte= mpting to allocate.
Since unexec is disabled, I don't even understa= nd why avoiding mmap'ed memory is important.=C2=A0 Pure space is just g= oing to be copied into the cold storage area of the pdmp file anyway, no?= =C2=A0=C2=A0
In any case, changing the small amount to 20000 made= the issue go away for the purpose of testing, but I'm not sure why the= re isn't some comparison of the size of the object to the small amount = in the logic - either determining the minimum to allocate in one chunk, or = attempting to obtain a contiguous chunk by successive xzallocs until the re= quired size is obtained.

Lynn


--0000000000006a416105e4c9af49-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 27 10:00:26 2022 Received: (at 56793) by debbugs.gnu.org; 27 Jul 2022 14:00:26 +0000 Received: from localhost ([127.0.0.1]:56575 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGhaM-0004sJ-De for submit@debbugs.gnu.org; Wed, 27 Jul 2022 10:00:26 -0400 Received: from mail-ej1-f50.google.com ([209.85.218.50]:43933) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGhaK-0004ro-QL for 56793@debbugs.gnu.org; Wed, 27 Jul 2022 10:00:25 -0400 Received: by mail-ej1-f50.google.com with SMTP id b11so31575453eju.10 for <56793@debbugs.gnu.org>; Wed, 27 Jul 2022 07:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aMOjQPC/ai5T4wwnxBoJU8blepxHtH6veYVHvVKxvAo=; b=jMfJiv0Mv7x6RmE3MAkaDsQLt7NQeDyWmmAiqCpwFSrFHs7Pv/1edk0cKyuypxVlgG 3gv6d+raOtrn36N9d8WY3GT+SCuisydCpamw10CAdue05Q4Od/TW7TOTEQX0GKzbPEO5 +0oKTDLk8YHkKICWwkLmmGwWKBc4C5kqhEsXD1V7Q/KRaXkXwOZeGmq6gDjDyVzIW7pf Fvqys1aLvskbCJuIDp7up8uZHxTggq26BLnAEV5CI55hUcf6Jv9LEBV1xqzYQSHAp4Ii T0ISpXjf5CAU13HrITkmIiCJ5Ok0Ov1tpLTttmZoT1ap8ABVoMLKMH2fUehgBqKZLgem K74A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aMOjQPC/ai5T4wwnxBoJU8blepxHtH6veYVHvVKxvAo=; b=dW4uUMzn/P+2093naOse1W2BSEXd2BUTk/DnHQIOGRADCbQY2MfE5E50DqeOCUhs0l B5Jb0OZp6/3lLR3JmyAYsxEjHYasDHaTMvpTV3nDkbR396qhGKZdPFlvdFY4ZbJSajBj cVR51KjNcyGZX4h0aZ9Es3Sdj0Lzqv+n6HP1FkexGxzjbp+QB/e57rimvdyPFKBB7i7F 76wOCkb1Z34DCIuGPJ0OvdVPiFZvoTpbxUgbHzzEr/arv+8NbBC8XNFo9lLezx4kmenA iJB0dsexIp37gb3qOiOF6+qeDpYAPHiHtJlmiCEwntKQ3swOgGJxQlQFta1k9aoBFxYv wNZw== X-Gm-Message-State: AJIora+2Hm9hAefQomjMy1OpTArHQXqUPSf0qOQRYvgKj/MlRYYqRVJn P+x9jMXNQ3Lm/cWF1gjO+Y00SabOk2WtXIPQ8lw= X-Google-Smtp-Source: AGRyM1tndSCDuGqIHXIles+ufocLf795tdHfkJA5xpQWqvOOCcnFVpajBATUeYH9dpLZsCDgiCHQdp9Kypcmn6lCufI= X-Received: by 2002:a17:907:608d:b0:72f:191b:7625 with SMTP id ht13-20020a170907608d00b0072f191b7625mr18271445ejc.754.1658930417670; Wed, 27 Jul 2022 07:00:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Pip Cet Date: Wed, 27 Jul 2022 13:59:39 +0000 Message-ID: Subject: Re: bug#56793: Infinite loop in pure_alloc when dumping strings longer than 10K bytes To: Lynn Winebarger Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56793 Cc: 56793@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Wed, Jul 27, 2022 at 1:51 PM Lynn Winebarger wrote: > I apologize for not being able to include significant details of the build, as this is happening on a sandboxed system in a proprietary context. > I've been attempting to dump emacs built from the 28.1 tarball with a large number of core libraries preloaded. I have observed runaway allocation when attempting to dump with native-compilation enabled and with native-compilation disabled. I believe this is a duplicate of #46916, which was closed as WONTFIX. (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46916) There's a patch there, IIRC. Pip From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 27 10:22:17 2022 Received: (at 56793) by debbugs.gnu.org; 27 Jul 2022 14:22:17 +0000 Received: from localhost ([127.0.0.1]:56628 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGhvV-0005WT-Fj for submit@debbugs.gnu.org; Wed, 27 Jul 2022 10:22:17 -0400 Received: from mail-pg1-f178.google.com ([209.85.215.178]:40920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGhvS-0005WB-ID for 56793@debbugs.gnu.org; Wed, 27 Jul 2022 10:22:16 -0400 Received: by mail-pg1-f178.google.com with SMTP id f11so16048238pgj.7 for <56793@debbugs.gnu.org>; Wed, 27 Jul 2022 07:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BIYbomEpIUi1aBeivuf0hw+TnkFGP2RBWfsoGOeztI0=; b=k5lDDi7A2TF68R1eembpIr7WdeyH2OT1FyvqDFDyXamHgfhOE+faR6peRfdcbk18Rv mYpdREZ2+trXTW0i1w3yb2SbZ9GwqJIzZqYn0xAgfIUO6CahzeCUTGW+gWimk3GEd/qM aGW7uVSeenpkDhopVi2k83ZHCVw7/KJZEAWoGqO2ra1m/JMcpfH/wbOsRusQRnYwA4sE ZHk3a5MXBBkrnao5PndtFPuK2P5CRBbZhxck6tgiWy4iibuQz24r/G0lQtyp/rVonKCr A5nYl69TlPWlpSZXkpwZLsfu9v0zo954hgk5XUqVzbQSBTdoSUmyiwIUE9QPy+hln9RB 6YVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BIYbomEpIUi1aBeivuf0hw+TnkFGP2RBWfsoGOeztI0=; b=CrVgmmcw4bzbvtyvjYbvMSY82QRJciBaiW+gj+mEEn/iCUsB1tFVtFmXyQLvudfQnF 7gjcCVzkwfZirHjnemIm3K9ex1dAXXhBlsfryO3v+fqNMGbFamHDL2+lG0YIlrNI9RD5 LyhJmiRmedJiwozuz598ET/fVyOXmKmTEEvpg7AkcfkwbZtRANH0qI1fVggwTZd0j+Cu nbWx4c08jqdtl2egh2/RyoIY7T+zrFYJDVQIcCOmEwIK+HTcIaU30yGtXBgt1AI+tyco X+hc6E/XrACIj5tgZiSvmFowCT1wPYuuVNs9hwZU6IgWsGHfuhoWGPZd6Y3ZZ/BUo2UH VtLA== X-Gm-Message-State: AJIora+NSHgEtOhhYt/tLlan8Ul6cuGiP7LbTTyLTmes47tPqkubTjcX wL58VVdu7l2dldwEVZq/gl9qPmNPD+JWHyw3+pU= X-Google-Smtp-Source: AGRyM1uqVj37mYn2agSS1w5XDqKR5yf1lBew+QMbvq4vF1Tu27XiLzresI+1dJka5L7FA3uc3M6f53aVNtqtRrcNW/M= X-Received: by 2002:a63:6888:0:b0:3fe:49fc:3be3 with SMTP id d130-20020a636888000000b003fe49fc3be3mr18220189pgc.182.1658931728463; Wed, 27 Jul 2022 07:22:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lynn Winebarger Date: Wed, 27 Jul 2022 10:21:55 -0400 Message-ID: Subject: Re: bug#56793: Infinite loop in pure_alloc when dumping strings longer than 10K bytes To: Pip Cet Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56793 Cc: 56793@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Wed, Jul 27, 2022 at 10:00 AM Pip Cet wrote: > > On Wed, Jul 27, 2022 at 1:51 PM Lynn Winebarger wrote: > > I apologize for not being able to include significant details of the build, as this is happening on a sandboxed system in a proprietary context. > > I've been attempting to dump emacs built from the 28.1 tarball with a large number of core libraries preloaded. I have observed runaway allocation when attempting to dump with native-compilation enabled and with native-compilation disabled. > > I believe this is a duplicate of #46916, which was closed as WONTFIX. > (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46916) There's a patch > there, IIRC. > True, but the triggering issue doesn't really seem to be pure space exhaustion per se. Nominal pure space exhaustion doesn't even seem to prevent producing a portable dump file - unless the object is over 10K bytes in size. I understand the long-term solution, but in the meantime we should still be able to dump emacs with additional files without runaway allocation. Lynn From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 27 10:29:24 2022 Received: (at 56793) by debbugs.gnu.org; 27 Jul 2022 14:29:24 +0000 Received: from localhost ([127.0.0.1]:56644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGi2O-0005iZ-I7 for submit@debbugs.gnu.org; Wed, 27 Jul 2022 10:29:24 -0400 Received: from mail-pl1-f173.google.com ([209.85.214.173]:42743) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGi2L-0005iI-0l for 56793@debbugs.gnu.org; Wed, 27 Jul 2022 10:29:23 -0400 Received: by mail-pl1-f173.google.com with SMTP id d7so16251522plr.9 for <56793@debbugs.gnu.org>; Wed, 27 Jul 2022 07:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=leJUqwWiKG22IE9EIXHnbO1DwdvTbwLypGLrsqLlemY=; b=iA5lTQ2x8lGkS/kz4CWQ44LDjlEEkzZibpkr1KuJaMvY7alaBUGXymEEm6pzv0Sans J/gwAs/AVp72KiQD4VRgt0reDs1USLH8fDMozsuy1BjEGQtINKuw4rMEwASyIxj2f+Hr 06H6NTV7WjsXC0evPFmX2mmjPCwlGVFiGTSZcZjaqO+jQ1dMFoI2EjmuFPDJTbH2tCQX kBt0/49aYzrS1cupPOOVuMh48N/DSLkPZblqc4FL1tosB2ARUwO6MtpEGlKZF3DYya/t oWtJMNZRZEsZwmsYXDzCujBXhQwMdMGMTTxfCfiUU0tMB07zzYEyKWlm2xNEjOnZvP2s zlmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=leJUqwWiKG22IE9EIXHnbO1DwdvTbwLypGLrsqLlemY=; b=azLJC0NdhDMGBmuQZgDOcV29QP3zW1RZl7rhKOj6MUS9BcfwODV6JpJMntp9ttcPlW IRId8z2L0CUrtjbkle6KJ4EXwMCnMigFXmT/+NJRtbLMScQNXrOUeOxK+RWWZYBD9FdO IzerJv0Bk5H4Q/LfqoCtHHRkW7UOv5tlLKY8+NmJGhyKOLyuv3yD1QE3KA5rWqnWj5fZ cZJeabgTY2gykNxhxA6ke+W/iUvACSp+UgpFSdGja3SW+mr2ERL8xJSfR93WuXEe5h2Q K/QE6fTIbnNxoexD+MbvWUYIF25Pt+SDFd6dBzya5aii71QJaDmUNsgt2B8C7lp5BsI6 Jd3Q== X-Gm-Message-State: AJIora/TP8As5I9LkCDQYwNHpuVtKFc3BaZzdXQx1ZypVbvDIms7+qJQ T9Bq0J0j1iiNRzvK9LR3DcUcWFLYdCLtiasmZH8= X-Google-Smtp-Source: AGRyM1sX0yCqXNybWuaI3GOUuG/JjFKwyqwg0+HJlcd4dC/L3R1WxFIQnswcCCJ9WFGo0rpZ6G3u7KsQkqFu0q/+6xg= X-Received: by 2002:a17:90b:149:b0:1f2:f657:2f17 with SMTP id em9-20020a17090b014900b001f2f6572f17mr5009272pjb.203.1658932155188; Wed, 27 Jul 2022 07:29:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lynn Winebarger Date: Wed, 27 Jul 2022 10:29:02 -0400 Message-ID: Subject: Re: bug#56793: Infinite loop in pure_alloc when dumping strings longer than 10K bytes To: Pip Cet Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56793 Cc: 56793@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Wed, Jul 27, 2022 at 10:21 AM Lynn Winebarger wrote: > > On Wed, Jul 27, 2022 at 10:00 AM Pip Cet wrote: > > > > On Wed, Jul 27, 2022 at 1:51 PM Lynn Winebarger wrote: > > > I apologize for not being able to include significant details of the build, as this is happening on a sandboxed system in a proprietary context. > > > I've been attempting to dump emacs built from the 28.1 tarball with a large number of core libraries preloaded. I have observed runaway allocation when attempting to dump with native-compilation enabled and with native-compilation disabled. > > > > I believe this is a duplicate of #46916, which was closed as WONTFIX. > > (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46916) There's a patch > > there, IIRC. > > > True, but the triggering issue doesn't really seem to be pure space > exhaustion per se. Nominal pure space exhaustion doesn't even seem to > prevent producing a portable dump file - unless the object is over 10K > bytes in size. > > I understand the long-term solution, but in the meantime we should > still be able to dump emacs with additional files without runaway > allocation. Also, in that archived bug correspondence, it wasn't clear that Eli noticed that the user is no longer notified that pure space has been exhausted to know that they need to increase it. The manual indicates that there will be an error stating that pure space has been exhausted - I didn't realize it was until I tracked down this bug. I was thinking I would get some indication of how much additional pure space would be required. All I know for sure is that setting SITELOAD_PURESIZE_EXTRA to 10^6 did not prevent the issue. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 12 09:03:42 2025 Received: (at 56793-done) by debbugs.gnu.org; 12 Feb 2025 14:03:42 +0000 Received: from localhost ([127.0.0.1]:33408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tiDL3-0008Cd-Oz for submit@debbugs.gnu.org; Wed, 12 Feb 2025 09:03:42 -0500 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]:44344) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tiDL1-0008CK-Hg for 56793-done@debbugs.gnu.org; Wed, 12 Feb 2025 09:03:40 -0500 Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-5de63846e56so8143923a12.1 for <56793-done@debbugs.gnu.org>; Wed, 12 Feb 2025 06:03:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739369013; x=1739973813; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=F8XkAQ42sTllVvmJqShrJ5Z/eWEfnKCHTZpjFy3PYdA=; b=QIe3tj9NYRImdrDyj+idVlRJpBKQNiATeW8r4KVwSzdvYfsXpJjoIiLRElZY5FfzQY ykb8enUPBcsiPm3iVip+isQ83ApWyip5WcHuRGp8miaurv2uqTWr27o7vWptWFP8s200 WSZg1l1+I1esmGn56OSJXnstr28UHxhgL1W5ps1sFo9pTWTM6mAC6e73tL55CcB9sErv UFp/M4HqapA0b9XcGH8VOED3J72vAa3B9yXmAHxoaz7WNTg9My3WMsoH6MmjyLruwtKY kSlnM8KEY2mzKvifyZcTQc6vF4JL0ScR0awDwP+rFMJbKXx/au1OZPEo689uNyTS6ATU ZqsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739369013; x=1739973813; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=F8XkAQ42sTllVvmJqShrJ5Z/eWEfnKCHTZpjFy3PYdA=; b=XVrVdWnYhoFqs4FkoEljOXhCikucOsZVZ4R5dwYTw/5bvN0WozZ+wHdQnnFZ47ONBb VhDjXh4WyUddPzesO/nnVVsUxPDt0YFJJeavh8L+qBZBVdm3eEO6fxP3BWIe81R3Il9K pd99M5ojPZoS1fdCT4RvC+fs2rrNzhNHIA9yQijr2ah4icFSPL8138ErSUQ5PbTIJZzf cS8SXISRPt71IWo0NE/HCiBOzZiRrEvzhHK0szb4Q5rXsRw4smFJ3bAcUJaLDe7/pJW4 Hl7YthK67X3F1VmKcOIqxZqiXnB5vrIwN4hdGhKjwQ4ZmXBqFd2CtzvyEmEjv9rYCK9A wChg== X-Forwarded-Encrypted: i=1; AJvYcCX7KfqbjL1aAMVwpCmmferA3V2nfP54MaPrRUL/FqolWJBMBEtOHymoHd3LMku71JPvcD3aRZNwE6Vb@debbugs.gnu.org X-Gm-Message-State: AOJu0YysXDRYRPhk0w6/mo9lXTP97aNQy1Gn92J/gv0XgEJBV1gd+GYV GbdsJF997Zq0QgQ/1Ack2xia5Tl14WYtJ3TSR7uYk36C5RRjXpALkMkLXWRkXNaHzYsZkdpuFlP Ernsp5cIhcxOF5qfAlUlPFAjLLkj045KcYceAFw== X-Gm-Gg: ASbGncuCraAAUjOOyUG8pXVwT1rETEW/RltmH0Nsepq8fFMcpHnC4r+49GkJ6NDjkm6 wiJ+OkFe6f2j8TV5EADCkVdBTo6152K0ibil35lnbcGa3AKwUK2QRMAUFNKhBWQl8RUKaeb1fNb U= X-Google-Smtp-Source: AGHT+IFMEm1y8hweW3mrxf00KCU+cBd8/QPtrNAbFouqMVNbp4JEE04pqVv6BoP2f8E++0+67NxoPP04v5TnC//93F0= X-Received: by 2002:a05:6402:34d2:b0:5d0:ed71:3ce4 with SMTP id 4fb4d7f45d1cf-5deb086a2c7mr2582297a12.6.1739369012985; Wed, 12 Feb 2025 06:03:32 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 12 Feb 2025 06:03:32 -0800 From: Stefan Kangas In-Reply-To: References: MIME-Version: 1.0 Date: Wed, 12 Feb 2025 06:03:32 -0800 X-Gm-Features: AWEUYZkK8jBfW0BjTk-1pkYTWN3vFJd1C2_GCSpme2u7vehNbU7e9Q_Mhcdh0WA Message-ID: Subject: Re: bug#56793: Infinite loop in pure_alloc when dumping strings longer than 10K bytes To: Pip Cet Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56793-done Cc: 56793-done@debbugs.gnu.org, Lynn Winebarger X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > On Wed, Jul 27, 2022 at 1:51 PM Lynn Winebarger wrote: >> I apologize for not being able to include significant details of the build, as this is happening on a sandboxed system in a proprietary context. >> I've been attempting to dump emacs built from the 28.1 tarball with a large >> number of core libraries preloaded. I have observed runaway allocation when >> attempting to dump with native-compilation enabled and with native-compilation >> disabled. > > I believe this is a duplicate of #46916, which was closed as WONTFIX. > (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46916) There's a patch > there, IIRC. Since purespace has been removed on master, I don't think there's anything more to do here. I'm therefore closing this bug report. From unknown Tue Jun 24 10:31:35 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 13 Mar 2025 11:24:29 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator