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

Previous Next

Package: emacs;

Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Date: Sat, 24 Sep 2022 13:46:01 UTC

Severity: normal

Found in version 29.0.50

Fixed in version 29.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #41 received at 58042 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58042 <at> debbugs.gnu.org
Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal 
Date: Mon, 26 Sep 2022 07:13:05 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: 58042 <at> debbugs.gnu.org
>> Date: Sun, 25 Sep 2022 10:28:48 +0200
>> 
>> So, the question seems to be what scenario would create a live string
>> that points into a freed sdata struct.
>
> That sounds highly improbable to me.  But stranger things have
> happened...

Yeah :-/.

In the meantime, and in an attempt to get some more information, I've
made me a script that starts Emacs in LLDB, with my init file, and exits
Emacs after a delay, and then does things in LLDB depending on what
happened.

I left that script running over night, and the result wasn't very
helpful.  After almost 2 hours of running, I got an ASAN error in
copyRect:(NSRect)srcRect to:(NSPoint)dest, nsterm.m.  And LLDB crashed
again.

This is with HEAD 568920a5b703e80c43e1b6f31778ea5776218a1e.

I meanwhile wonder what that all means.  An "invalid display" that isn't
reproducible, a crash in regexp, a crash in copyRect, and then the
crashes in LLDB itself.

I think I'll let that sit for a bit.




This bug report was last modified 2 years and 73 days ago.

Previous Next


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