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