GNU bug report logs - #58042
29.0.50; ASAN use-after-free in re_match_2_internal

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58042 <at> debbugs.gnu.org
Subject: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal
Date: Wed, 05 Oct 2022 09:34:30 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> What I can see is that, apparently, redisplay got called because Emacs
>> received a MacOS event, and did a prepare_menu_bars etc etc.
>
> You mean, a macOS event can be received asynchronously, and will
> interrupt some processing in C, like inside regex-emacs.c?

If it can, I don't know.  But is the GC during redisplay is the one
moving the string, that would be the consequence, I think.

> If that can happen, no code in Emacs is safe, ever.  I don't believe
> this is possible: we no longer process window-system events
> asynchronously, AFAIK, and for this very reason.  But maybe macOS is
> different?  In that case, either we should change the macOS code to
> avoid doing that, or we should have some means of blocking such
> "interrupts" around specific code fragments, akin to block_input.

Yeah.  It would be good if that wouldn't happen ever, if it can.

If it can't happen, then the GC in redisplay that we see is not directly
related to all of this. and your question how redisplay can run while
matching is also off the table, I think.  I don't know a way how that
could happen.

But some GC must run and move strings around.  I don't know how else to
explain the invalid pointer.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.