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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 23 Jun 2022 07:53:29 +0200
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: 56108@debbugs.gnu.org
> 
> On 22. Jun 2022, 18:20 +0200, Eli Zaretskii <eliz@gnu.org>, wrote:
> 
>  I think the next step is to add the missing freeze_pattern calls and
>  see if that fixes the problem?
> 
> I think the missing freezes are 100% a bug, and they should be fixed.

I agree.

> Do you want to do that or should I? 

Feel free to do it, I generally prefer that people who see the problem
and could at least potentially test the solution also make the change
to fix it.

> Another side question, if I may: Have you perhaps heard of someone producing a static call graph for
> Emacs, or better yet, specific functions in Emacs?  Maybe using objdump -D or something similar? 

Does this make sense in a dynamic program such as Emacs?  We call into
Lisp quite a lot from C, and from there you can arrive anywhere, no?
And objdump cannot capture Lisp levels.

That is, btw, the main problem with maintaining Emacs internals
nowadays: it is hard, almost impossible, to know, just by looking at C
code, whether GC or any other Lisp-related activity could happen
between two arbitrary lines of C.  We have more and more hooks called
from C that could potentially call any Lisp, and we have more and more
direct calls into Lisp from the most intimate parts of Emacs, like the
display engine and the main loop in keyboard.c.  This basically makes
any analysis of whether or not some code fragment could cause GC
futile: even if today it's impossible, it can easily become possible
tomorrow, with some innocent-looking change.  This is exacerbated by
the fact that GCPROs are long gone, so the caution we used to
exercised 20 years ago to make sure GC doesn't surprise us is no
longer needed nor practiced.

But no, I don't think anyone tried to see what kind of graph could be
obtained.  Maybe it's worthwhile, who knows? we might learn something
useful regardless.