bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size"

[npostavs]

tags 24358 patch
quit

Eli Zaretskii <eliz@gnu.org> writes:
>
> Then yes, you will need to somehow pass down the object from which the
> text comes.  It can be in some global variable, for instance, if
> changing the function's signature is undesirable.

I decided that a global variable would be a bad idea since it would
still effectively be part of the calling convention, and too easy for
callers to forget.  But just after finishing the patch I noticed this:

    /* In Emacs, this is the string or buffer in which we
       are matching.  It is used for looking up syntax properties.  */
    Lisp_Object re_match_object;

So now I'm thinking it might be better to reuse that variable instead.
Although it only seems to get to Qt, Qnil, and string objects; I'm not
sure what the meaning of Qt and Qnil are.

v1-0001-Fix-handling-of-allocation-in-regex-matching.patch
Description: patch v1

Sam Halliday <sam.halliday@gmail.com> writes:
>
> Could somebody please let me know how to dig into 0x56e5508 (if
> relevant)? I have never used gdb in anger.

See if you can adapt the .gdbinit modifications I posted in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24358#53; assuming your
recipe always triggers the crash in the exact same way, it might be
enough just to change the conditional to 'if (lim == 1156)', and you
might not even need the ignore call at all.

> I've attempted to workaround this in ensime by simplifying our loading
> of the .ensime file (the s-expression) to use with-temp-buffer and not
> declaring .ensime as an emacs-lisp file... it may be that one of my
> minor modes, active in emacs-lisp, is performing a regexp that is
> triggering this bug.

If you can get the lisp backtrace it should show you what code is
triggering the regexp search.  It should show up automatically when you
do bt, if you've sourced src/.gdbinit as described in etc/DEBUG
"Configuring GDB".