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

From: Lynn Winebarger <[email-masked]>
Date: Wed, 27 Jul 2022 10:29:02 -0400

On Wed, Jul 27, 2022 at 10:21 AM Lynn Winebarger <[email-masked]> wrote:
>
> On Wed, Jul 27, 2022 at 10:00 AM Pip Cet <[email-masked]> wrote:
> >
> > On Wed, Jul 27, 2022 at 1:51 PM Lynn Winebarger <[email-masked]> 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.