From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs 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-ID: References: <83mvx8252m.fsf@gnu.org> <55E34714.7080608@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1144ac342d99ec051e8becd1 X-Trace: ger.gmane.org 1440961248 12275 80.91.229.3 (30 Aug 2015 19:00:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Aug 2015 19:00:48 +0000 (UTC) Cc: 21380@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 30 21:00:30 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZW7ps-0005N3-AR for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Aug 2015 21:00:12 +0200 Original-Received: from localhost ([::1]:60079 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZW7ps-0000jm-Bf for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Aug 2015 15:00:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZW7po-0000ge-0f for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 15:00:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZW7pk-0001CI-RT for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 15:00:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50828) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZW7pk-0001BK-PA for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 15:00:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZW7pj-0003CS-SX for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 15:00:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Aug 2015 19:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21380 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21380-submit@debbugs.gnu.org id=B21380.144096119812268 (code B ref 21380); Sun, 30 Aug 2015 19:00:03 +0000 Original-Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 18:59:58 +0000 Original-Received: from localhost ([127.0.0.1]:43038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW7pe-0003Bn-0x for submit@debbugs.gnu.org; Sun, 30 Aug 2015 14:59:58 -0400 Original-Received: from mail-io0-f175.google.com ([209.85.223.175]:35264) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW7pc-0003Bf-0Z for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 14:59:56 -0400 Original-Received: by iog7 with SMTP id 7so14787450iog.2 for <21380@debbugs.gnu.org>; Sun, 30 Aug 2015 11:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=my2PkLwoJ6imghupre2s2HylUxbmmPBHh6aeap8I+Zo=; b=yGNl+8ud0D3HRYSWjafZyLNN79VgjiKAXOdLD1ool6vKmgPNmdx9wu60ONmCyXO2sf Pd7ilPJzXeEE4eDq7+FBujiLEwQL4gKBHoJRlvsacNId211etewnvaneAsoMFAxo77Yk 8S3c1j/O9RpreRLyuFY1ti9BcokyifGkmBlWqy2E4P25m89iHu7sT5e7NyamFMDC3kxs WuqADoKxqyzKToY2JQUtPAFQuk/b9wnOjNK+PNYJZSR5srPqytH07OFS0Q7iAHqt9Akw re0ZVbHRyZ0eUbtUV6YWAe0BTeiPeP7Zn7o5j7xcEfc3dlqUGV0LhuhjSD0Pt8DNvIXQ 2ePg== X-Received: by 10.107.47.97 with SMTP id j94mr21867283ioo.136.1440961195250; Sun, 30 Aug 2015 11:59:55 -0700 (PDT) Original-Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 11:59:55 -0700 (PDT) In-Reply-To: <55E34714.7080608@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:105989 Archived-At: --001a1144ac342d99ec051e8becd1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Aug 30, 2015 at 6:10 PM, martin rudalics 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 =E2=80=98window-configuration-chang= e-hook=E2=80=99 > and subsequently cause the havoc you describe. The last > change_frame_size should have just happened three lines before. > But that had delay =3D=3D 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). --001a1144ac342d99ec051e8becd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, 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.
=C2=A0
But I have no idea why this particular call
of do_pending_window_change would run =E2=80=98window-configuration-change-= hook=E2=80=99
and subsequently cause the havoc you describe.=C2=A0 The last
change_frame_size should have just happened three lines before.

But that had delay =3D=3D true, so ch= ange_frame_size_1 never called adjust_frame_size, right?
=C2=A0
> And my current understanding is this bug would not occur if that call = were
> removed.

...but possibly that w= ouldn't work because of other things being called from GTK event handle= rs.

Just thinking out loud for the rest of the Email:
=
I'm somewhat hesitant to mention this idea, but wouldn't it b= e 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 fram= e destruction by GTK (I'm creating and destroying many Emacs frames in = my test code).
--001a1144ac342d99ec051e8becd1--