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

[Eli Zaretskii <eliz@gnu.org>]

> From: npostavs@users.sourceforge.net
> Cc: 24358@debbugs.gnu.org,  peder@klingenberg.no
> Date: Sat, 08 Oct 2016 12:57:32 -0400
> 
> >> Old value = 68 'D'
> >> New value = 0 '\000'
> >
> > If that string is data of a Lisp string, then a call to malloc could
> > relocate the data.  Code that holds C pointers into buffer or string
> > text should either use SREF, or recompute the C pointer after each
> > function call which could GC.
> 
> In that case, I believe the problem is that search_buffer calls
> re_search_2 with a pointer to the buffer text, and then
> re_match_2_internal (called by re_search_2), can allocate when doing
> PUSH_FAILURE_POINT because it eventually does SAFE_ALLOCA to grow the
> regex stack.
> 
> AFAICT, this bug is still present 24.5, but because re_max_failures is
> set to a round number (see
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24358#27), there are fewer
> calls to malloc and thus less chance of relocating the particular string
> in question.
> 
> So possible solutions I can would be to pass down the lisp reference to
> re_match_2_internal, or else set re_max_failures according to MAX_ALLOCA
> (but this would make it much smaller).

Do you see buffer text actually changing its address in this scenario?
Otherwise, we might be chasing a wild goose.

(Once we establish this is the problem, we could talk about the fix.
IME, pointers could still be passed, but some extra caution is needed
when using them.)

Thanks.