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 14:52:26 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >
> > Do you see buffer text actually changing its address in this scenario?
> > Otherwise, we might be chasing a wild goose.
> 
> Yes, now that I know what to look for, it's easy enough.  I added just
> this to .gdbinit:
> 
>     break search_command if (bound == 0)
>     commands
>       watch current_buffer->text->beg
>       continue
>     end
>     # break only on the 2nd call to search_command
>     ignore 3 1
> 
> And here is the result:
> 
>     Thread 1 "emacs" hit Breakpoint 3, search_command (string=25301860, bound=0, noerror=44544, count=0, 
>         direction=1, RE=1, posix=false) at search.c:1024
>     1024	  EMACS_INT n = direction;
>     Hardware watchpoint 4: current_buffer->text->beg
> 
>     Thread 1 "emacs" hit Hardware watchpoint 4: current_buffer->text->beg
> 
>     Old value = (unsigned char *) 0x18351b8 ""
>     New value = (unsigned char *) 0x188a1b8 ""
>     r_alloc_sbrk (size=290816) at ralloc.c:818

r_alloc_sbrk?  What OS is this?  We only use ralloc.c on a handful of
them, as of Emacs 25.

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).

Thanks.