bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#24358: 25.1.50; re-search-forward errors with "Variable binding dept


From: Noam Postavsky
Subject: bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size"
Date: Sun, 23 Oct 2016 19:18:32 -0400

Eli Zaretskii <eliz@gnu.org> wrote:
> Noam, do you configure Emacs with --enable-check-lisp-object-type?
> If not, please do, because that's what Sam does; perhaps that is the
> reason why he gets the problem and you don't.
>
> One other difference is that Sam is running a bootstrap, so his
> bootstrap-emacs used to build ja-dic has the necessary Lisp files
> loaded as *.el files, not *.elc.  Therefore another thing to try
> (perhaps even before reconfiguring) is a full bootstrap, preferably in
> a separate clean directory, maybe you will see this problem then.

I will try both of these tomorrow.

Sam, if you want to post the docker thing somewhere I can give that a
try tomorrow as well, in case Eli's suggestions are not sufficient to
reproduce this.

> Noam, there's something I don't understand here: why is regex.c using
> malloc for allocating the failure stack?  AFAICS, REGEX_MALLOC is not
> defined, so the only way I can explain this to myself is that we use
> SAFE_ALLOCA, and that falls back to malloc because the failure stack
> needs more than 16KB of memory.  Is that correct?

Yes, this is correct, see also
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24358#47

>
> If so, then one other way of solving the original problem that doesn't
> open the gates of the ralloc.c hell is to allow a larger amount of
> stack allocations in regex.c before we fall back to malloc.  Since the
> maximum size of the failure stack is limited by something like 800KB,
> and the C stack limit is set in main.c to allow the failure stack be
> allocated off the stack, why don't we make use of this fact?

It sounds reasonable in principle. This would mean changing MAX_ALLOCA?





reply via email to

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