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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: gerd.moellmann@gmail.com,  56108@debbugs.gnu.org
> Date: Thu, 23 Jun 2022 17:29:13 -0400
> 
> Before `freeze_pattern`, the design was that nothing could happen while
> running the regexp matcher (no GC, no execution of Lisp code).
> 
> Commit 938d252d1c6c5e2027aa250c649deb024154f936 changed that so that
> searching inside a *buffer* could end up running ELisp code (and hence
> also GC).  AFAIK this still can't happen when searching in strings.
> [ IIRC The need to run ELisp is so as to apply `syntax-table` text
>   properties on demand via `syntax-propertize`.  ]
> 
> So I think freeze_pattern should be used in all cases where
> `compile_pattern` is used to search inside a buffer, but it shouldn't be
> necessary when searching within a string.

I think at least the scenario uncovered by Gerd, shown in this
backtrace-like form:

> maybe_gc
> Ffuncall
> call2 
> signal_or_quit (eval.c:1741)
> quit (eval.c:1697)
> process_quit_flag (eval.c:1657)
> probably_quit (eval.c:1864)
> maybe_quit (lisp.h:3681)
> re_match_2_internal (regexp-emacs.c:4691)

could happen even when searching within strings.  And in general, as I
tried to explain up-thread, relying on what cannot happen _today_ wrt
GC is not future-proof, the way Emacs development advances.

So I think we should install a change that calls freeze_pattern for
every pattern-cache entry as long as it is in use.

Gerd, would you please show the patch for that?