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

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]

On 23. Jun 2022, 08:58 +0200, Eli Zaretskii <eliz@gnu.org>, wrote:
> > 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.
> >
Ok
> >
> > 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.
True, but for GC at least, I think it would make it easier to tell if it can potentially happen. One would see a call to GC in the static call graph. Not for arbitrary lines, of course, you know what I mean...
> >
> > 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.
> >
All true, I just want to remark that I have no fond memories of GCPRO, and of debugging stuff caused by missing ones.   Glad to hear they're finally completely dead now.
> >
> > 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.
Thanks

[-- Attachment #2: Type: text/html, Size: 3788 bytes --]