bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> What I can see is that, apparently, redisplay got called because Emacs
>> received a MacOS event, and did a prepare_menu_bars etc etc.
>
> You mean, a macOS event can be received asynchronously, and will
> interrupt some processing in C, like inside regex-emacs.c?

If it can, I don't know.  But is the GC during redisplay is the one
moving the string, that would be the consequence, I think.

> If that can happen, no code in Emacs is safe, ever.  I don't believe
> this is possible: we no longer process window-system events
> asynchronously, AFAIK, and for this very reason.  But maybe macOS is
> different?  In that case, either we should change the macOS code to
> avoid doing that, or we should have some means of blocking such
> "interrupts" around specific code fragments, akin to block_input.

Yeah.  It would be good if that wouldn't happen ever, if it can.

If it can't happen, then the GC in redisplay that we see is not directly
related to all of this. and your question how redisplay can run while
matching is also off the table, I think.  I don't know a way how that
could happen.

But some GC must run and move strings around.  I don't know how else to
explain the invalid pointer.