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

From: Pip Cet <[email-masked]>
Date: Sun, 30 Aug 2015 18:59:55 +0000

On Sun, Aug 30, 2015 at 6:10 PM, martin rudalics <[email-masked]> wrote:

> In my understanding the do_pending_window_change call is not needed and
> usually should be a noop.

May I ask why? I don't understand this code very well.

> But I have no idea why this particular call
> of do_pending_window_change would run ‘window-configuration-change-hook’
> and subsequently cause the havoc you describe.  The last
> change_frame_size should have just happened three lines before.
>

But that had delay == true, so change_frame_size_1 never called
adjust_frame_size, right?

> > And my current understanding is this bug would not occur if that call
> were
> > removed.

...but possibly that wouldn't work because of other things being called
from GTK event handlers.

Just thinking out loud for the rest of the Email:
I'm somewhat hesitant to mention this idea, but wouldn't it be best for GTK
events to generate special input events (like we already do for
asynchronous frame switches?), and let the command loop handle those? I've
just hit what appears to be another bug caused by asynchronous frame
destruction by GTK (I'm creating and destroying many Emacs frames in my
test code).