GNU bug report logs - #56793
Infinite loop in pure_alloc when dumping strings longer than 10K bytes

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Lynn Winebarger <owinebar <at> gmail.com>
Subject: bug#56793: closed (Re: bug#56793: Infinite loop in pure_alloc
 when dumping strings longer than 10K bytes)
Date: Wed, 12 Feb 2025 14:04:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#56793: Infinite loop in pure_alloc when dumping strings longer than 10K bytes

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 56793 <at> debbugs.gnu.org.

-- 
56793: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56793
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 56793-done <at> debbugs.gnu.org, Lynn Winebarger <owinebar <at> gmail.com>
Subject: Re: bug#56793: Infinite loop in pure_alloc when dumping strings
 longer than 10K bytes
Date: Wed, 12 Feb 2025 06:03:32 -0800

Pip Cet <pipcet <at> gmail.com> writes:

> On Wed, Jul 27, 2022 at 1:51 PM Lynn Winebarger <owinebar <at> gmail.com> 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.

[Message part 3 (message/rfc822, inline)]

From: Lynn Winebarger <owinebar <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Infinite loop in pure_alloc when dumping strings longer than 10K bytes
Date: Wed, 27 Jul 2022 09:49:13 -0400

[Message part 4 (text/plain, inline)]

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

[Message part 5 (text/html, inline)]

Previous Next

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