all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Gerd Möllmann" <gerd.moellmann@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 56108@debbugs.gnu.org
Subject: bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal
Date: Thu, 23 Jun 2022 10:24:31 +0200	[thread overview]
Message-ID: <84b39f74-b1dd-4485-b501-fc4a7e634455@Spark> (raw)
In-Reply-To: <835ykrg93i.fsf@gnu.org>

[-- 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 --]

  parent reply	other threads:[~2022-06-23  8:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-20 14:07 bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal Gerd Möllmann
2022-06-20 19:09 ` Eli Zaretskii
2022-06-22  8:13   ` Gerd Möllmann
2022-06-22 13:38     ` Eli Zaretskii
2022-06-22 14:10       ` Gerd Möllmann
2022-06-22 14:24         ` Eli Zaretskii
2022-06-22 15:11           ` Gerd Möllmann
2022-06-22 16:19             ` Eli Zaretskii
2022-06-23  5:53               ` Gerd Möllmann
2022-06-23  6:57                 ` Eli Zaretskii
2022-06-23  7:17                   ` Eli Zaretskii
2022-06-23 21:29                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-24  5:55                       ` Eli Zaretskii
2022-06-24  6:01                         ` Gerd Möllmann
2022-06-24  9:35                           ` Gerd Möllmann
2022-06-24 15:40                             ` Eli Zaretskii
2022-06-25  9:18                               ` Eli Zaretskii
2022-06-27 13:26                             ` Eli Zaretskii
2022-06-27 13:29                               ` Gerd Möllmann
2022-06-23  8:24                   ` Gerd Möllmann [this message]
2022-06-23  8:37                     ` Eli Zaretskii
2022-06-23  8:49                       ` Gerd Möllmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84b39f74-b1dd-4485-b501-fc4a7e634455@Spark \
    --to=gerd.moellmann@gmail.com \
    --cc=56108@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.