bug#40661: Crash in regex search during redisplay

[Richard Copley <rcopley@gmail.com>]

On Thu, 16 Apr 2020 at 18:24, Daniel Colascione <dancol@dancol.org> wrote:
>
> On 4/16/20 9:56 AM, Richard Copley wrote:
> > On Thu, 16 Apr 2020 at 17:42, Daniel Colascione <dancol@dancol.org> wrote:
> >>
> >> On April 16, 2020 9:33:16 AM PDT, Eli Zaretskii <eliz@gnu.org> wrote:
> >>>> Date: Thu, 16 Apr 2020 18:36:36 +0300
> >>>> From: Eli Zaretskii <eliz@gnu.org>
> >>>> Cc: 40661@debbugs.gnu.org
> >>>>
> >>>> Looks like GC sometimes kicks in while we are inside re_search_2
> >>>
> >>> Or not.  I cannot get a breakpoint inside GC to fire while we are in
> >>> search_buffer_re, so maybe my hypothesis was wrong.  Although the
> >>> symptoms are all there: when the segfault hits, the pointers passed to
> >>> re_search_2 are invalid, but BEGV_ADDR and GAP_END_ADDR, from which
> >>> they are supposed to be computed, are valid (and different).  And the
> >>> patch does seem to avoid the segfaults.  But maybe it's just a
> >>> coincidence or a side effect...
> >>
> >> Try using rr and see where those pointers came from
> >
> > It seems clear from "str1=str1@entry=0xc607fd", etc., that they come
> > from the caller, search_buffer_re. The question is, why are they no
> > longer valid after updating syntax?
>
> Right. So let's see what updated the valid pointers and invalidated the
> invalid ones.

Right, I see. Anyway, I wasn't able to reproduce the bug under
GNU/Linux (in order to use rr), or make much progress with GDB on
Windows.