On Tue, Jul 26, 2022, 10:48 PM Lynn Winebarger <owinebar@gmail.com> wrote:

> On Tue, Jul 26, 2022 at 8:58 PM Lynn Winebarger <owinebar@gmail.com>
> wrote:
> > I was still seeing some runaway allocation even with native
> > compilation completely disabled, so I finally fired up gdb and found
> > the culprit:  "lmalloc", which has a comment saying the "while (true)"
> > loop shouldn't iterate on a modern platform.  RHEL 7.9 isn't hot off
> > the presses, but it's not that ancient.
> > I'll try to replicate on a personal machine and file a bug, but it's
> > not clear what triggers the condition. When it does occur, it always
> > occurs at the same place.  One instance was from loading cc-mode in
> > site-load (after byte-compiling all the dependencies in the correct
> > order).  I wrapped the "defun c-init-language-vars-for" sexp in an
> > eval, based on a comment in another one of the cc-* files (i.e.
> > cargo-cult programming on my part), and that stopped the runaway
> > allocation.  But then it happened while loading ibuffer.el.
>
> Wrong again - the infinite loop is in pure_alloc.  It looks like there
> is a 10,655 character string in ibuffer.el on which pure_copy is being
> called, and pure_alloc only adds increments of 10k.
> This I can report as a bug.
>

The segmentation faults I've seen are also coming from purecopy.  It's
attempting to traverse a cyclic lisp structure and overflows the stack.

I'm going guess this kind of thing is why Stefan Monnier and Pip Cet were
enthusiastic about ditching pure space.

Lynn