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

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Cc: 24358@debbugs.gnu.org,  peder@klingenberg.no
> Date: Sat, 08 Oct 2016 09:45:20 -0400
> 
> >> From: npostavs@users.sourceforge.net
> >> Date: Fri, 07 Oct 2016 20:29:36 -0400
> >> Cc: 24358@debbugs.gnu.org
> >> 
> >> npostavs@users.sourceforge.net writes:
> >> >
> >> >> (I'm also on GNU/Linux, Arch) I get the same max-specpdl-size error with
> >> >> 25.1.50, with 24.5 (and below) I get (error "Stack overflow in regexp
> >> >> matcher")
> >> 
> >> icalendar--read-element has been fixed, but this still reproduces when
> >> doing (re-search-forward ".*\\(\n.*\\)*" nil t) on the text file given
> >> in the OP.
> >
> > Isn't that "user error"?
> 
> Yes, but it should give "Stack overflow in regexp matcher", not overflow
> the lisp stack (or assertion failure).

But that's what you said (see above): "Stack overflow in regexp
matcher".  That's what I meant when I said "user error".

> I show some more excerpts in the attached bug-24358-debug.log, but my
> main finding is that string1 of re_match_2_internal is originally:
> 
>     string1=0x1835980 "DESCRIPTION;LANGUAGE=
> 
> but then it becomes corrupted during a malloc:
> 
> 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.

Thanks.