GNU bug report logs - #21380
25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21380 <at> debbugs.gnu.org
Subject: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook
Date: Tue, 1 Sep 2015 16:56:04 +0000

[Message part 1 (text/plain, inline)]

On Tue, Sep 1, 2015 at 4:04 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Tue, 1 Sep 2015 15:14:09 +0000
> > From: Pip Cet <pipcet <at> gmail.com>
> > Cc: 21380 <at> debbugs.gnu.org
> >
> > (* - well, one segfault. But I attribute that to extraordinarily bizarre
> > actions even by my standards: attempting to display an unprintable ASCII
> > control character in the echo area.
>
> Is this reproducible?  If so, please submit a separate bug report with
> a recipe.
>

#21394.

>
> > Usually this is fine because propertized strings never end up in the
> > echo area (I hope)...)
>
> The echo area is a normal buffer, so any face can be used in it.  See,
> for example, the message printed by info.el after "i SOMETHING RET".
>

Thanks for explaining! You're right, then, it's a bug.

> That only prevents us from reading new events from the X socket, but
> what if some signal that is already pending invokes some Lisp?

I don't understand. How can we call "some signal that is already pending"
(I'm not sure what that means. A unix signal? Or just something that sets
pending_signals to a true value? Or an atimer?) when input_blocked_p () is
true? The only thing gobble_input () does in that case is
store_user_signal_events (), which doesn't call any Lisp.

The only code path that I see that's potentially dangerous is that atimers
appear to be executed even if input is blocked.

[Message part 2 (text/html, inline)]

Previous Next

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