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

[Pip Cet]

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

> Date: Tue, 1 Sep 2015 15:14:09 +0000
> From: Pip Cet <pipcet@gmail.com>
> Cc: 21380@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.