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?