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: martin rudalics <rudalics <at> gmx.at>
Cc: 21380 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook
Date: Sun, 30 Aug 2015 18:59:55 +0000

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

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

[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.