GNU bug report logs - #56561
29.0.50; Infloop in try_window

Previous Next

Package: emacs;

Reported by: Michael Welsh Duggan <md5i <at> md5i.com>

Date: Thu, 14 Jul 2022 18:58:01 UTC

Severity: normal

Found in version 29.0.50

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: luangruo <at> yahoo.com
Cc: mwd <at> md5i.com, 56561 <at> debbugs.gnu.org
Subject: bug#56561: 29.0.50; Infloop in try_window
Date: Fri, 15 Jul 2022 18:27:15 +0300
> Cc: mwd <at> md5i.com, 56561 <at> debbugs.gnu.org
> Date: Fri, 15 Jul 2022 17:24:26 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Po Lu <luangruo <at> yahoo.com>
> > Cc: mwd <at> md5i.com,  56561 <at> debbugs.gnu.org
> > Date: Fri, 15 Jul 2022 21:54:24 +0800
> > 
> > BTW, I have a question about the fix: redisplay cannot run when a
> > tooltip is displayed as popup menu help-text, so adjust_glyph_matrix and
> > the subsequent try_window call that is required to generate the display
> > contents will not be called in time, leading to a blank tooltip.
> > 
> > The call could previously never fail, since the tooltip code specifies
> > TRY_WINDOW_IGNORE_FONTS_CHANGE.
> > 
> > Would it be appropriate to call adjust_frame_glyphs and try_window again
> > if this call to try_window in Fx_show_tip fails?
> 
> You mean, adjust_frame_glyphs, right?
> 
> We probably should do that

On second thought, I take this back.  I don't see how we could have a
blank tooltip.  We call try_window just so we could compute the size
of the text in it, which then allows us to know the size of the
tooltip.  The situation where nrows_scale_factor is increased happens
when we get to the bottom of the window, which for a tooltip means we
already laid out all the text and are just producing empty glyph rows
beyond the end of the text.  ncols_scale_factor could theoretically
happen before we reach the end of the text, but I'd like to see
something like that happening before I believe it; and even if it does
happen in the very first line, the tooltip will not be empty, just
truncated.

So I cannot see how this case could produce an empty tooltip, and I
have hard time imagining how it could even produce a truncated text.
We could add an assertion to verify that try_window gets to ZV in this
case before it returns, if we want to be able to detect those cases.

> We need a recipe to trigger the reverse, to be able to test a
> solution.

That part is still true.




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

Previous Next


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