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

[Stefan Monnier]

>>> Isn't the -[EmacsView layoutSublayersOfLayer:] the problem?  AFAICT from
>>> a web search, this is an event handler method that is also called from
>>> by the framework?
>>>
>>> In the olden days, it was a serious error to call into Lisp from an
>>> event handler.  All bets were off when that happened, not only related
>>> to GC.  I believe that hasn't changed much.
>
> Today, event handling code calls Lisp all the time (through safe_call
> etc.)  That happens in handle_one_xevent, ns_select, et cetera.

Really?

> It shouldn't affect GC at all because input is blocked for the entire
> duration of each GC, except for when finalizers are run after unmarked
> objects are sweeped.

The problem was not if it's run from within the GC, the problem was what
this code does when *it* runs the GC (or other state-changing functions).
[ And indeed, the fix Gerd installed was to prevent GC while running
  pending_signals.  But I suspect this is not sufficient because there
  are other forms of global state that can get messed up.  ]

In bug#62732 we have a related problem when code run from `maybe_quit`
(an atimer in that case) from the regexp engine, and that atimer
itself performs a regexp-operation, which messes up the outer regexp
engine invocation because the regexp engine is still not re-entrant (in
that bug, the problem is the `gl_state` global variable).


        Stefan