Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook

From: Pip Cet <[email-masked]>
Date: Tue, 1 Sep 2015 16:56:04 +0000

On Tue, Sep 1, 2015 at 4:04 PM, Eli Zaretskii <[email-masked]> wrote:

> > Date: Tue, 1 Sep 2015 15:14:09 +0000
> > From: Pip Cet <[email-masked]>
> > Cc: [email-masked]
> >
> > (* - 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.