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: Eli Zaretskii
Subject: bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size"
Date: Mon, 24 Oct 2016 10:05:58 +0300

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sun, 23 Oct 2016 19:18:32 -0400
> Cc: Sam Halliday <sam.halliday@gmail.com>, 24358@debbugs.gnu.org
> 
> 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.

Thanks.

Here are some other things to try, if you (or someone else) have time:

  . build regex.c with REGEX_MALLOC defined, and see whether your
    recent additions to cater to relocation are needed with that
    configuration
  . build with gmalloc.c, but without ralloc.c (I will try to come up
    with a recipe or a patch for that later today, if no one beats me
    to it)
  . surround the calls to regex.c functions in search.c and elsewhere
    with the calls to r_alloc_inhibit_buffer_relocation, again without
    your recent additions to regex.c (the problem with this is that it
    must be tested in long, real-life sessions, because in the past
    using that workaround caused very rare crashes in ralloc.c itself,
    which were supposed to be fixed, but were never tested thoroughly
    enough, AFAIK)

> > 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?

Actually, it probably means using a different definition for
SAFE_ALLOCA in regex.c, or a separate macro.  I don't see the need to
increase stack usage elsewhere in Emacs.

Thanks.





reply via email to

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