GNU bug report logs - #58334
29.0.50; ASAN heap use after free in gui_produce_glyphs

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: luangruo <at> yahoo.com, 58334 <at> debbugs.gnu.org
Subject: Re: bug#58334: 29.0.50; ASAN heap use after free in gui_produce_glyphs
Date: Fri, 07 Oct 2022 14:19:58 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  58334 <at> debbugs.gnu.org
> Date: Fri, 07 Oct 2022 10:54:34 +0200
> 
> Po Lu <luangruo <at> yahoo.com> writes:
> 
> > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> >
> >> And, while vaccuming, I also wondered what happens with the glyph
> >> matrices, and maybe other global state?
> >
> > Isn't input blocked wherever the glyph matrices are modified?
> > If not,
> 
> Partly.  Eli please correct me if this has changed.
> 
> Redisplay has two phases:
> 
> 1. Building desired matrices, that is, what should be on the screen
> after redisplay.
> 
> 2. Updating current matrices from desired matrices, and bringing that on
> the screen.
> 
> Only phase 2 has input blocked because the current matrices are
> modified, which are shared state with the GUI code.

I don't see input blocked in phase 2, either.  We interrupt phase 2 if
input is pending, but even that only in some cases.

The GUI code runs in the same thread as phase 2, so there's no reason
to synchronize anything here, AFAIU.  If you are thinking about
expose_frame and friends, then that was changed years ago not to run
from the signal handler, so it cannot cause any problems to code that
modifies the glyph matrices.

Previous Next

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