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: Tue, 1 Sep 2015 16:56:04 +0000 Message-ID: References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <837foaceid.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0102f83ef9abc7051eb26cee X-Trace: ger.gmane.org 1441126642 29988 80.91.229.3 (1 Sep 2015 16:57:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Sep 2015 16:57:22 +0000 (UTC) Cc: 21380@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 01 18:57:13 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 1ZWorv-0006Rs-BW for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Sep 2015 18:57:11 +0200 Original-Received: from localhost ([::1]:55974 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWoru-000320-Vb for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Sep 2015 12:57:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWorp-00031n-LT for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2015 12:57:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWorm-0003YT-P8 for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2015 12:57:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53097) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWorm-0003X2-CN for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2015 12:57:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZWorl-0008Tu-Vf for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2015 12:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Sep 2015 16:57:01 +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.144112656832542 (code B ref 21380); Tue, 01 Sep 2015 16:57:01 +0000 Original-Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 16:56:08 +0000 Original-Received: from localhost ([127.0.0.1]:45307 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWoqu-0008Sn-1L for submit@debbugs.gnu.org; Tue, 01 Sep 2015 12:56:08 -0400 Original-Received: from mail-ig0-f175.google.com ([209.85.213.175]:33720) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWoqr-0008Sf-OU for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 12:56:06 -0400 Original-Received: by igbkq10 with SMTP id kq10so5843985igb.0 for <21380@debbugs.gnu.org>; Tue, 01 Sep 2015 09:56:05 -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=hfp/QfR5ivNJ3o6IYxtuHIzWTo8VuPuZaJ2R0+hExII=; b=dDzQp9g8PIA+L1153/veMSuNwqFuML0VhMsgVxbrj9qk81RnFeAPEtziN7U5MAy9z3 pkgekUH0cocnuMGQy+9AtXcWRBlmYBMiAr00d3DJTkCdwagYJ7/oLwrfxZnHXDVmNMPl 9ufJQJKZ6BkkhMUMYkyvUObdQ/aV4zUIzU0Qz0QPIag9GD/yDkQvVWBEWl2iULRaEviL 1/Q28BdtzJPxjvSdIZKcl/lpSgh8o2ACXqm9cMxI36cOWPPhoGy3xattcbKu9pOmfVzd DmRIXMpR6M0l+MWxbP2+CKP5at49Km5mNJ6uGc6dTK+6oyiDXfKjRZwgst3dlPhv4MPd AkgA== X-Received: by 10.50.112.227 with SMTP id it3mr3598288igb.93.1441126564865; Tue, 01 Sep 2015 09:56:04 -0700 (PDT) Original-Received: by 10.79.78.66 with HTTP; Tue, 1 Sep 2015 09:56:04 -0700 (PDT) In-Reply-To: <837foaceid.fsf@gnu.org> 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:106062 Archived-At: --089e0102f83ef9abc7051eb26cee Content-Type: text/plain; charset=UTF-8 On Tue, Sep 1, 2015 at 4:04 PM, Eli Zaretskii wrote: > > Date: Tue, 1 Sep 2015 15:14:09 +0000 > > From: Pip Cet > > 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. --089e0102f83ef9abc7051eb26cee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 1, 2015 at 4:04 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Tue, 1 Sep 2= 015 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 ASC= II
> control character in the echo area.

Is this reproducible?=C2=A0 If so, please submit a separate bug repo= rt with
a recipe.

#21394.
=C2=A0
> 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.=C2= =A0 See,
for example, the message printed by info.el after "i SOMETHING RET&quo= t;.

Thanks for explaini= ng! You're right, then, it's a bug.

> That only prevents us from reading new events from the X sock= et, but
> what if some signal that is already pending invokes some Li= sp?

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 (), whi= ch doesn't call any Lisp.

The o= nly code path that I see that's potentially dangerous is that atimers a= ppear to be executed even if input is blocked.
--089e0102f83ef9abc7051eb26cee--