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

[Eli Zaretskii <eliz@gnu.org>]

> X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_40,FREEMAIL_FROM,
> 	T_DKIM_INVALID autolearn=disabled version=3.3.2
> From: npostavs@users.sourceforge.net
> Cc: 24358@debbugs.gnu.org,  peder@klingenberg.no
> Date: Thu, 13 Oct 2016 22:19:09 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: npostavs@users.sourceforge.net
> >> Cc: 24358@debbugs.gnu.org,  peder@klingenberg.no
> >> Date: Wed, 12 Oct 2016 21:29:34 -0400
> >> 
> >> > Anyway, the way to countermand this is to record in a local variable
> >> > the offset from beginning of buffer text to the value of the C pointer
> >> > before the call to record_xmalloc, then apply the offset after the
> >> > call to the new buffer text address.  (Let me know if this is clear
> >> > enough.)
> >> >
> >> > You can find an example of this in coding.c:decode_coding_emacs_mule
> >> > (search for "relocated" in that function).
> >> 
> >> This does involve passing down the lisp reference, right?  Just want to
> >> make sure I'm not missing something obvious before I start changing the
> >> interface on a bunch of functions.
> >
> > Aren't we talking about searching buffer text in this case?  If so,
> > the start address of the buffer text is known globally, it is given by
> > current_buffer->text->beg.
> 
> The particular crash reported is during a buffer search, but the bug is
> in re_match_2_internal which (if I understand correctly) may be called
> for string search as well.

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.