GNU bug report logs - #72692
Emacs 31.05 (40eecd594ac) get SIGSEGV on Linux (Linux 6.6.45 Kde Wayland)

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>, Po Lu <luangruo <at> yahoo.com>
Cc: pipcet <at> protonmail.com, execvy <at> gmail.com, 72692 <at> debbugs.gnu.org
Subject: Re: bug#72692: Emacs 31.05 (40eecd594ac) get SIGSEGV on Linux
 (Linux 6.6.45 Kde Wayland)
Date: Thu, 29 Aug 2024 13:06:07 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: pipcet <at> protonmail.com,  execvy <at> gmail.com,  72692 <at> debbugs.gnu.org
> Date: Wed, 28 Aug 2024 22:02:44 +0300
> 
> The breakpoint inside 'if (non_basic_faces_cached)'
> is triggered on every character inserted by Pip's recipe.
> So the condition in your patch works in this test,
> whereas it's never triggered in normal use.

Thanks, I've now installed the change in xfaces.c.

The fact that we hit that breakpoint for every character bothered me,
so I looked into it.  It turns out we do that because the test calls
set-frame-parameter inside the loop to set the frame's
alpha-background parameter.  But the value of alpha-background is the
same in all the calls: 1.0.  So this call is basically a no-op, but
gui_set_alpha_background, which is the handler of alpha-background
parameter, doesn't check that the value is the same, and not only sets
the same value, but also recomputes all the basic faces (on the
assumption that alpha-background changed).  It also sets the frame's
garbaged flag.  This is silly, since we are shooting ourselves in the
foot by slowing down the following redisplay cycle: it will need to
re-realize all the faces and also perform a thorough redisplay of all
of the frame's windows.

Then I looked at the other handlers of frame parameters, and it turns
out almost none of them check that the new value is different,
although they all receive the old value as their last argument!

Po Lu, is there any reason why frame-parameter handlers for GUI frames
should ignore the fact that the new value of a parameter is exactly
equal to the old value?  Is there some subtle issue here, and if so,
does it affect all the parameters or only some?

If there's no real reason for this, I think we should teach the
handlers to do nothing if the new value is identical to the old one.

Previous Next

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