[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Loading tramp for dump goes into infinite regress

From: Lynn Winebarger
Subject: Re: Loading tramp for dump goes into infinite regress
Date: Wed, 27 Jul 2022 04:31:30 -0400

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]