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

[Pip Cet]

On Sun, Aug 30, 2015 at 6:10 PM, martin rudalics <rudalics@gmx.at> 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).