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

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Pip Cet <pipcet@HIDDEN>; dated Sun, 30 Aug 2015 12:52:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 2 Sep 2015 16:09:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 02 12:09:56 2015
Received: from localhost ([127.0.0.1]:46639 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZXAbj-00054w-QY
	for submit <at> debbugs.gnu.org; Wed, 02 Sep 2015 12:09:56 -0400
Received: from mail-io0-f173.google.com ([209.85.223.173]:35474)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZXAbh-00054n-Oa
 for 21380 <at> debbugs.gnu.org; Wed, 02 Sep 2015 12:09:54 -0400
Received: by ioiz6 with SMTP id z6so25751088ioi.2
 for <21380 <at> debbugs.gnu.org>; Wed, 02 Sep 2015 09:09:53 -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=h10uoZxl6T8Jt3RUQjeBVMNDkonBtVa5xYlCSXbTvmI=;
 b=jWhiQX++mc2gJgxUqU3DOCSL/A+o0d/GMleptrovnmwcPCAASErgaRqCcuteKfbypA
 gYqBFdoo/oY++6UBHqvdf6KERwhPapWdme+fuB01U/QUbzmyy89UeKXcbILWCifkd10s
 sXdsVMnjx6fnUxGWVxqkxA8r2AaJh5IAf2eZ5XxpVnBvb885sKm/ggZIWCMoldYTakx4
 Ynzx3A0oQTAzKpCME5mSNDXjVDfXeh3MA6CgZqylwomtXhD/GGsQf9yvwBcQ4JXT/j9j
 a52XYU4kZjzhRYeWwqeIuUXUQhHldWikXj0fm7iJuF5oLGqUavD7ASPIUcFPz6m2TjgF
 HcmQ==
MIME-Version: 1.0
X-Received: by 10.107.163.19 with SMTP id m19mr41758552ioe.65.1441210193182;
 Wed, 02 Sep 2015 09:09:53 -0700 (PDT)
Received: by 10.79.78.66 with HTTP; Wed, 2 Sep 2015 09:09:53 -0700 (PDT)
In-Reply-To: <83a8t4c10v.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
 <83a8t71qct.fsf@HIDDEN>
 <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
 <CAOqdjBfy8KdZnNSB5NBdwkYk=AMG9MMezyGgH06yM5S=Q35Fcw@HIDDEN>
 <837foaceid.fsf@HIDDEN>
 <CAOqdjBdiYySbRS4xvVfK2zx+KiSskJOwHEZK7=t_gwP3Wqm+4g@HIDDEN>
 <83vbbuawgy.fsf@HIDDEN>
 <CAOqdjBd-LLOERx78ngF_n3fQM+O6zKbF3gbEme9t8Jwb7iT3RQ@HIDDEN>
 <83a8t4c10v.fsf@HIDDEN>
Date: Wed, 2 Sep 2015 16:09:53 +0000
Message-ID: <CAOqdjBf4_h92OJU2foDFOUMMJGZADdgB28=Ch9q-gdEA7Ms6BQ@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=001a114035589c8631051ec5e5ef
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a114035589c8631051ec5e5ef
Content-Type: text/plain; charset=UTF-8

On Wed, Sep 2, 2015 at 3:08 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > Date: Tue, 1 Sep 2015 20:48:18 +0000
> > From: Pip Cet <pipcet@HIDDEN>
> > Cc: 21380 <at> debbugs.gnu.org
> >
> >     Alternatively, we could turn off atimers (by calling turn_on_atimers)
> >     while Fcopy_sequence runs.
> >
> >
> > I think that would be a better solution. I've done a quick grep for the
> current
> > atimers and at first glance they appear to be okay, but obviously that's
> no
> > guarantee for the future. It might be worth thinking about
> > block_input_and_atimers ().
> >
> > I think it's safe to assume that Lisp timers are only checked if atimers
> are
> > enabled.
>
> Those are two completely separate and independent features, so no,
> it's not safe to make that assumption.  Not sure why you need to
> assume that, though.
>

So we can call turn_on_atimers (true) without potentially enabling atimers
in a critical section.

My assumption was that the reason we have both Lisp timers and atimers is
that atimers run strictly more often than Lisp timers.


> > If it isn't, I think the best way forward is to write
> > block_input_and_atimers () and lock atimers with a counter just like
> input is.
>
> Not sure I follow you.  Are you saying that just calling block_input
> followed by turn_on_atimers is somehow not enough to prevent some Lisp
> from changing Vtimer_list under our feet?
>

I'm not saying that, no, but if another function disables atimers, then
runs Lisp timers, then does something critical that needs atimers to be
disabled, it might break.

> --- a/src/fns.c
> > +++ b/src/fns.c
> > @@ -744,6 +744,9 @@ concat (ptrdiff_t nargs, Lisp_Object *args,
> >           /* Store this element into the result.  */
> >           if (toindex < 0)
> >             {
> > +                if (NILP (tail))
> > +                  break;
> > +
>
> Is this part still needed?


As far as I know, the other two fixes are sufficient. It's needed in case
someone calls copy_sequence on a list that's messed with by code run from a
hook from QUIT, and merely succeeds in avoiding a segfault and producing
incorrect results instead, so I'm not at all sure it should go in.

--001a114035589c8631051ec5e5ef
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Sep 2, 2015 at 3:08 PM, Eli Zaretskii <span dir=3D=
"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a=
>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">&gt; Date: Tue, 1 Sep 2015 20:48:18 +0000<=
br>
<span>&gt; From: Pip Cet &lt;<a href=3D"mailto:pipcet@HIDDEN" target=3D"=
_blank">pipcet@HIDDEN</a>&gt;<br>
&gt; Cc: <a href=3D"mailto:21380 <at> debbugs.gnu.org" target=3D"_blank">21380@d=
ebbugs.gnu.org</a><br>
&gt;<br>
</span><span>&gt;=C2=A0 =C2=A0 =C2=A0Alternatively, we could turn off atime=
rs (by calling turn_on_atimers)<br>
&gt;=C2=A0 =C2=A0 =C2=A0while Fcopy_sequence runs.<br>
&gt;<br>
&gt;<br>
&gt; I think that would be a better solution. I&#39;ve done a quick grep fo=
r the current<br>
&gt; atimers and at first glance they appear to be okay, but obviously that=
&#39;s no<br>
&gt; guarantee for the future. It might be worth thinking about<br>
&gt; block_input_and_atimers ().<br>
&gt;<br>
&gt; I think it&#39;s safe to assume that Lisp timers are only checked if a=
timers are<br>
&gt; enabled.<br>
<br>
</span>Those are two completely separate and independent features, so no,<b=
r>
it&#39;s not safe to make that assumption.=C2=A0 Not sure why you need to<b=
r>
assume that, though.<br></blockquote><div><br></div><div>So we can call tur=
n_on_atimers (true) without potentially enabling atimers in a critical sect=
ion.<br><br></div><div>My assumption was that the reason we have both Lisp =
timers and atimers is that atimers run strictly more often than Lisp timers=
.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span>
&gt; If it isn&#39;t, I think the best way forward is to write<br>
&gt; block_input_and_atimers () and lock atimers with a counter just like i=
nput is.<br>
<br>
</span>Not sure I follow you.=C2=A0 Are you saying that just calling block_=
input<br>
followed by turn_on_atimers is somehow not enough to prevent some Lisp<br>
from changing Vtimer_list under our feet?<br></blockquote><div><br></div><d=
iv>I&#39;m not saying that, no, but if another function disables atimers, t=
hen runs Lisp timers, then does something critical that needs atimers to be=
 disabled, it might break.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

&gt; --- a/src/fns.c<br>
&gt; +++ b/src/fns.c<br>
&gt; @@ -744,6 +744,9 @@ concat (ptrdiff_t nargs, Lisp_Object *args,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Store this element into the=
 result.=C2=A0 */<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (toindex &lt; 0)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (NILP (tai=
l))<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;=
<br>
&gt; +<br>
<br>
Is this part still needed?</blockquote><div><br></div><div>As far as I know=
, the other two fixes are sufficient. It&#39;s needed in case someone calls=
 copy_sequence on a list that&#39;s messed with by code run from a hook fro=
m QUIT, and merely succeeds in avoiding a segfault and producing incorrect =
results instead, so I&#39;m not at all sure it should go in.<br></div></div=
></div></div>

--001a114035589c8631051ec5e5ef--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 2 Sep 2015 15:08:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 02 11:08:08 2015
Received: from localhost ([127.0.0.1]:46589 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZX9dw-0003Wu-6Z
	for submit <at> debbugs.gnu.org; Wed, 02 Sep 2015 11:08:08 -0400
Received: from mtaout26.012.net.il ([80.179.55.182]:43817)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1ZX9dq-0003WP-1P
 for 21380 <at> debbugs.gnu.org; Wed, 02 Sep 2015 11:08:06 -0400
Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il
 (HyperSendmail v2007.08) id <0NU200J00223KB00@HIDDEN> for
 21380 <at> debbugs.gnu.org; Wed, 02 Sep 2015 18:10:11 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NU200BEY24YSA90@HIDDEN>; Wed, 02 Sep 2015 18:10:11 +0300 (IDT)
Date: Wed, 02 Sep 2015 18:08:00 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#21380: 25.0.50;
 GTK-induced segfault when scheduling timer from
 window-configuration-change-hook
In-reply-to: <CAOqdjBd-LLOERx78ngF_n3fQM+O6zKbF3gbEme9t8Jwb7iT3RQ@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Pip Cet <pipcet@HIDDEN>
Message-id: <83a8t4c10v.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
 <83a8t71qct.fsf@HIDDEN>
 <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
 <CAOqdjBfy8KdZnNSB5NBdwkYk=AMG9MMezyGgH06yM5S=Q35Fcw@HIDDEN>
 <837foaceid.fsf@HIDDEN>
 <CAOqdjBdiYySbRS4xvVfK2zx+KiSskJOwHEZK7=t_gwP3Wqm+4g@HIDDEN>
 <83vbbuawgy.fsf@HIDDEN>
 <CAOqdjBd-LLOERx78ngF_n3fQM+O6zKbF3gbEme9t8Jwb7iT3RQ@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Tue, 1 Sep 2015 20:48:18 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: 21380 <at> debbugs.gnu.org
> 
>     Alternatively, we could turn off atimers (by calling turn_on_atimers)
>     while Fcopy_sequence runs.
>     
> 
> I think that would be a better solution. I've done a quick grep for the current
> atimers and at first glance they appear to be okay, but obviously that's no
> guarantee for the future. It might be worth thinking about
> block_input_and_atimers ().
> 
> I think it's safe to assume that Lisp timers are only checked if atimers are
> enabled.

Those are two completely separate and independent features, so no,
it's not safe to make that assumption.  Not sure why you need to
assume that, though.

> If it isn't, I think the best way forward is to write
> block_input_and_atimers () and lock atimers with a counter just like input is.

Not sure I follow you.  Are you saying that just calling block_input
followed by turn_on_atimers is somehow not enough to prevent some Lisp
from changing Vtimer_list under our feet?

> --- a/src/fns.c
> +++ b/src/fns.c
> @@ -744,6 +744,9 @@ concat (ptrdiff_t nargs, Lisp_Object *args,
>  	    /* Store this element into the result.  */
>  	    if (toindex < 0)
>  	      {
> +                if (NILP (tail))
> +                  break;
> +

Is this part still needed?  If so, can you explain in what situation
it is needed?

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 2 Sep 2015 14:33:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 02 10:33:01 2015
Received: from localhost ([127.0.0.1]:46583 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZX95w-0002hz-Q6
	for submit <at> debbugs.gnu.org; Wed, 02 Sep 2015 10:33:01 -0400
Received: from mtaout29.012.net.il ([80.179.55.185]:39490)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1ZX95u-0002hp-Hv
 for 21380 <at> debbugs.gnu.org; Wed, 02 Sep 2015 10:32:59 -0400
Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il
 (HyperSendmail v2007.08) id <0NU200M000A96B00@HIDDEN> for
 21380 <at> debbugs.gnu.org; Wed, 02 Sep 2015 17:32:32 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NU200GC70E8OR80@HIDDEN>; Wed, 02 Sep 2015 17:32:32 +0300 (IDT)
Date: Wed, 02 Sep 2015 17:32:13 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#21380: 25.0.50;
 GTK-induced segfault when scheduling timer from
 window-configuration-change-hook
In-reply-to: <55E69F07.9060006@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: martin rudalics <rudalics@HIDDEN>
Message-id: <83h9ncc2oi.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
 <83a8t71qct.fsf@HIDDEN>
 <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
 <83fv2ychbg.fsf@HIDDEN>
 <CAOqdjBcNADPXuC+kXe5r0GmOk_i+xmnmwBJU2NhTb7sDVOsLXg@HIDDEN>
 <838u8qcenv.fsf@HIDDEN> <55E69F07.9060006@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Wed, 02 Sep 2015 09:02:31 +0200
> From: martin rudalics <rudalics@HIDDEN>
> CC: 21380 <at> debbugs.gnu.org
> 
>  > So maybe we should introduce a special copy_sequence_no_quit function
>  > that never calls QUIT, and then use it for copying the timer lists.
> 
> Yes.

I think we prefer the alternative that just blocks input and atimers
instead.

>  > Timer lists are never too long, so that shouldn't be a problem.
> 
> Why do you think that copy_sequence_no_quit would be slower than
> Fcopy_sequence?  The problem of copy_sequence_no_quit would be with
> circularity, not with length.

Sorry for being unclear.  I meant that the call to QUIT in
Fcopy_sequence is to allow the user to interrupt a too long copy, so I
think it won't be missed with timer lists, which are normally short.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 2 Sep 2015 07:02:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 02 03:02:39 2015
Received: from localhost ([127.0.0.1]:45825 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZX247-0007VF-Ix
	for submit <at> debbugs.gnu.org; Wed, 02 Sep 2015 03:02:39 -0400
Received: from mout.gmx.net ([212.227.17.21]:52661)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rudalics@HIDDEN>) id 1ZX245-0007V7-H6
 for 21380 <at> debbugs.gnu.org; Wed, 02 Sep 2015 03:02:38 -0400
Received: from [93.82.9.77] ([93.82.9.77]) by mail.gmx.com (mrgmx101) with
 ESMTPSA (Nemesis) id 0Lj61K-1YyETa0PPS-00dFMK; Wed, 02 Sep 2015 09:02:36
 +0200
Message-ID: <55E69F07.9060006@HIDDEN>
Date: Wed, 02 Sep 2015 09:02:31 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: Eli Zaretskii <eliz@HIDDEN>, Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>	<83mvx8252m.fsf@HIDDEN>	<CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>	<83k2sc20k6.fsf@HIDDEN>	<CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>	<83h9ng1ryx.fsf@HIDDEN>	<CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>	<83a8t71qct.fsf@HIDDEN>	<CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>	<83fv2ychbg.fsf@HIDDEN>	<CAOqdjBcNADPXuC+kXe5r0GmOk_i+xmnmwBJU2NhTb7sDVOsLXg@HIDDEN>
 <838u8qcenv.fsf@HIDDEN>
In-Reply-To: <838u8qcenv.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:XX5q8dMJbKs+JaSPdnhTueagrCVWA5i6dN2q/dOERhnY+lrbELc
 bIGzP7hqdlMA6MPUSxo82kWfp+72xUws3+bMQNIPEmYq1qaxd+iBPx6HDCW77bCo/BxWhYE
 7uEPcgSwv/aYy61Gg8D9Rd5N3WOgK+qoPRnp6gwTelkEZFxeZ+NIKP6o4Ob5Ur+Ba8IMSbH
 Wm2CnEEjktqWoZRrlXeXQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:ImCE8HnZEcc=:hYPxZI01125wmmwgHnnOo4
 hZXvnW4yp7hm7O93PEzAYYBCFnrfqhYU8sYrfDyNrzZqVIlPlnqXbjFY4JVm49RTP4JeOQAAc
 2UFlwsm5JLTuCvSJEuvyfymu5wzbASeS+K5fqCGTTapl4FxcdaXpOWYfdMyaJEgeioRTua7Gx
 bqdkG8eWwEjFe2ZWgeFggC4kM8yUjd9MBfvpTMaCYTeY/LBCIVRpd6neLa1V1XpxQNepIlzb/
 2aSgsdX9GAlbB+qch3F6log2jD75ybuPh8yeEw2fdQGInM2SlYyHIRBrnFWT+kAcGm8tk1mc8
 orlkeQpj7GHaFcevDHK/Qs8NMNE7vLWlbqSAgyhExQFQ0YJo4oBnwRKNXjlpa7OD2Jbyj6LGI
 AzzvuQSizqoITVOgip/jdGftJdoxDtSr82+3rNoZivfzybrRzKwlb6iGEC2PcuHWrheiVFIsA
 E6BZTs6zGsTqN8sEr+Jad6bxpVpvKkSojJ3v+WivSuAYCCN/6fkEESmcOuTXaySlQP+LOV1jg
 G27M8D1sjDWK2oGhqPim4iEg1ztwCvd2JLJcL5bfWNx8AGHI2b8AfEusbOuBjHpbib1PuCoJA
 RMAjsmE67R3PJkWho9mFmgSzlIyBjcG/qLwUCxln6fUJK/WoBXPmJ0vLF3E9AB8igJA96YHns
 R5I5+ktiOlERBpOqepk9jgm7I/GoBPEQk94ugoyY3vCVpVGYlBgPsj/OAVPnxo5bNqdmkwSGi
 T2m7R+wiXqtucGOGvKe2DMBM+zabkb9I25Nk5A==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

 > So maybe we should introduce a special copy_sequence_no_quit function
 > that never calls QUIT, and then use it for copying the timer lists.

Yes.

 > Timer lists are never too long, so that shouldn't be a problem.

Why do you think that copy_sequence_no_quit would be slower than
Fcopy_sequence?  The problem of copy_sequence_no_quit would be with
circularity, not with length.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 20:48:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 01 16:48:23 2015
Received: from localhost ([127.0.0.1]:45452 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZWsTe-0006vp-Jj
	for submit <at> debbugs.gnu.org; Tue, 01 Sep 2015 16:48:22 -0400
Received: from mail-ig0-f181.google.com ([209.85.213.181]:38119)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZWsTc-0006vh-M7
 for 21380 <at> debbugs.gnu.org; Tue, 01 Sep 2015 16:48:21 -0400
Received: by igbut12 with SMTP id ut12so10829050igb.1
 for <21380 <at> debbugs.gnu.org>; Tue, 01 Sep 2015 13:48:20 -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=+PS0IoLVGdfGQbl3ua74NXK3mrsBD/VwKbcdVZ9HA6A=;
 b=Tp/4LKLvsbPym4+abzDCrjl5MeFI9cFEIVLSv0W3UumgtAkHXXOHpZrYnqy6SPMv6B
 viyJUeaPvxv4nUVh1SZOZxU19VUGG8WrmAXHkLFWRSvKF1BkBSz1d8wzPZB1Oej2p16n
 ZbnrX+avByy3pk9R/WJE7gl0R7/0b5h6Auj/2SECddFrQ5xZ5drrC9dBhJOw0z2JR+Nv
 wbTnAKVdmD5iVPYBq7ehLtcJi+Nyz8T4cqS8wDCjqDDheOMJrKo+r+dcjjJjFfa55lOI
 pGhZEpj/dJ8upADwaWGWenITgn5k3cJxO1IC1sbIpg/ApTWK2+/ZT/S/x4VknYAshOTr
 NEKw==
MIME-Version: 1.0
X-Received: by 10.50.137.100 with SMTP id qh4mr148979igb.1.1441140498965; Tue,
 01 Sep 2015 13:48:18 -0700 (PDT)
Received: by 10.79.78.66 with HTTP; Tue, 1 Sep 2015 13:48:18 -0700 (PDT)
In-Reply-To: <83vbbuawgy.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
 <83a8t71qct.fsf@HIDDEN>
 <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
 <CAOqdjBfy8KdZnNSB5NBdwkYk=AMG9MMezyGgH06yM5S=Q35Fcw@HIDDEN>
 <837foaceid.fsf@HIDDEN>
 <CAOqdjBdiYySbRS4xvVfK2zx+KiSskJOwHEZK7=t_gwP3Wqm+4g@HIDDEN>
 <83vbbuawgy.fsf@HIDDEN>
Date: Tue, 1 Sep 2015 20:48:18 +0000
Message-ID: <CAOqdjBd-LLOERx78ngF_n3fQM+O6zKbF3gbEme9t8Jwb7iT3RQ@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/mixed; boundary=001a11c31f74834d6b051eb5abd4
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a11c31f74834d6b051eb5abd4
Content-Type: multipart/alternative; boundary=001a11c31f74834d66051eb5abd2

--001a11c31f74834d66051eb5abd2
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 1, 2015 at 5:19 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > The only code path that I see that's potentially dangerous is that
> atimers
> > appear to be executed even if input is blocked.
>
> Yes, that's exactly what bothered me.  Not calling QUIT prevents that.
>
> Alternatively, we could turn off atimers (by calling turn_on_atimers)
> while Fcopy_sequence runs.
>

I think that would be a better solution. I've done a quick grep for the
current atimers and at first glance they appear to be okay, but obviously
that's no guarantee for the future. It might be worth thinking about
block_input_and_atimers ().

I think it's safe to assume that Lisp timers are only checked if atimers
are enabled. If it isn't, I think the best way forward is to write
block_input_and_atimers () and lock atimers with a counter just like input
is.

--001a11c31f74834d66051eb5abd2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Sep 1, 2015 at 5:19 PM, Eli Zaretskii <span dir=3D=
"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a=
>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><span>
&gt; The only code path that I see that&#39;s potentially dangerous is that=
 atimers<br>
&gt; appear to be executed even if input is blocked.<br>
<br>
</span>Yes, that&#39;s exactly what bothered me.=C2=A0 Not calling QUIT pre=
vents that.<br>
<br>
Alternatively, we could turn off atimers (by calling turn_on_atimers)<br>
while Fcopy_sequence runs.<br>
</blockquote></div><br></div><div class=3D"gmail_extra">I think that would =
be a better solution. I&#39;ve done a quick grep for the current atimers an=
d at first glance they appear to be okay, but obviously that&#39;s no guara=
ntee for the future. It might be worth thinking about block_input_and_atime=
rs ().<br><br></div><div class=3D"gmail_extra">I think it&#39;s safe to ass=
ume that Lisp timers are only checked if atimers are enabled. If it isn&#39=
;t, I think the best way forward is to write block_input_and_atimers () and=
 lock atimers with a counter just like input is.<br></div><div class=3D"gma=
il_extra"><br></div></div>

--001a11c31f74834d66051eb5abd2--
--001a11c31f74834d6b051eb5abd4
Content-Type: text/x-patch; charset=US-ASCII; 
	name="0001-Fix-potential-race-conditions-Bug-21380.patch"
Content-Disposition: attachment; 
	filename="0001-Fix-potential-race-conditions-Bug-21380.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_ie1ttzd00

RnJvbSA2NzhiZGJhNTVlNGEwN2UzYmFlYmFkMjA0YzlmZTVjNTVjOTliM2QzIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXAgPHBpcGNldEBnbWFpbC5jb20+CkRhdGU6IFR1ZSwg
MSBTZXAgMjAxNSAyMDo0Mjo0NCArMDAwMApTdWJqZWN0OiBbUEFUQ0hdIEZpeCBwb3RlbnRpYWwg
cmFjZSBjb25kaXRpb25zIChCdWcjMjEzODApCgogICAgICAgICoga2V5Ym9hcmQuYyAodGltZXJf
Y2hlY2spOiBDYWxsIGBibG9ja19pbnB1dCcgYW5kIHR1cm4gb2ZmCglhdGltZXJzIGFyb3VuZCB0
aGUgY3JlYXRpb24gb2YgdGhlIHRlbXBvcmFyeSB0aW1lciBsaXN0IGNvcHkuCgoJKiBmbnMuYyAo
Y29uY2F0KTogRG9uJ3QgYXNzdW1lIGFyZ3VtZW50IHNpemUgcmVtYWlucyB1bmNoYW5nZWQKCWFm
dGVyIGNhbGwgdG8gYEZtYWtlX2xpc3QnLiAgUmV0dXJuIGluY29ycmVjdCByZXN1bHRzIChidXQg
ZG9uJ3QKCXNlZ2ZhdWx0KSBpbiB0aGF0IGNhc2UuCi0tLQogc3JjL2Zucy5jICAgICAgfCAzICsr
Kwogc3JjL2tleWJvYXJkLmMgfCA0ICsrKysKIDIgZmlsZXMgY2hhbmdlZCwgNyBpbnNlcnRpb25z
KCspCgpkaWZmIC0tZ2l0IGEvc3JjL2Zucy5jIGIvc3JjL2Zucy5jCmluZGV4IDI2YTk4YWIuLjE1
ZDllNjQgMTAwNjQ0Ci0tLSBhL3NyYy9mbnMuYworKysgYi9zcmMvZm5zLmMKQEAgLTc0NCw2ICs3
NDQsOSBAQCBjb25jYXQgKHB0cmRpZmZfdCBuYXJncywgTGlzcF9PYmplY3QgKmFyZ3MsCiAJICAg
IC8qIFN0b3JlIHRoaXMgZWxlbWVudCBpbnRvIHRoZSByZXN1bHQuICAqLwogCSAgICBpZiAodG9p
bmRleCA8IDApCiAJICAgICAgeworICAgICAgICAgICAgICAgIGlmIChOSUxQICh0YWlsKSkKKyAg
ICAgICAgICAgICAgICAgIGJyZWFrOworCiAJCVhTRVRDQVIgKHRhaWwsIGVsdCk7CiAJCXByZXYg
PSB0YWlsOwogCQl0YWlsID0gWENEUiAodGFpbCk7CmRpZmYgLS1naXQgYS9zcmMva2V5Ym9hcmQu
YyBiL3NyYy9rZXlib2FyZC5jCmluZGV4IGRhYjMyYjEuLjRjZTgzMGQgMTAwNjQ0Ci0tLSBhL3Ny
Yy9rZXlib2FyZC5jCisrKyBiL3NyYy9rZXlib2FyZC5jCkBAIC00NTYwLDYgKzQ1NjAsOCBAQCB0
aW1lcl9jaGVjayAodm9pZCkKIAogICBMaXNwX09iamVjdCB0ZW0gPSBWaW5oaWJpdF9xdWl0Owog
ICBWaW5oaWJpdF9xdWl0ID0gUXQ7CisgIGJsb2NrX2lucHV0ICgpOworICB0dXJuX29uX2F0aW1l
cnMgKGZhbHNlKTsKIAogICAvKiBXZSB1c2UgY29waWVzIG9mIHRoZSB0aW1lcnMnIGxpc3RzIHRv
IGFsbG93IGEgdGltZXIgdG8gYWRkIGl0c2VsZgogICAgICBhZ2Fpbiwgd2l0aG91dCBsb2NraW5n
IHVwIEVtYWNzIGlmIHRoZSBuZXdseSBhZGRlZCB0aW1lciBpcwpAQCAtNDU3Myw2ICs0NTc1LDgg
QEAgdGltZXJfY2hlY2sgKHZvaWQpCiAgIGVsc2UKICAgICBpZGxlX3RpbWVycyA9IFFuaWw7CiAK
KyAgdHVybl9vbl9hdGltZXJzICh0cnVlKTsKKyAgdW5ibG9ja19pbnB1dCAoKTsKICAgVmluaGli
aXRfcXVpdCA9IHRlbTsKIAogICBkbwotLSAKMi41LjAKCg==
--001a11c31f74834d6b051eb5abd4--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 17:19:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 01 13:19:17 2015
Received: from localhost ([127.0.0.1]:45318 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZWpDI-0000ZN-VH
	for submit <at> debbugs.gnu.org; Tue, 01 Sep 2015 13:19:17 -0400
Received: from mtaout29.012.net.il ([80.179.55.185]:50455)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1ZWpDG-0000ZE-Qq
 for 21380 <at> debbugs.gnu.org; Tue, 01 Sep 2015 13:19:15 -0400
Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il
 (HyperSendmail v2007.08) id <0NU000J00DCX2T00@HIDDEN> for
 21380 <at> debbugs.gnu.org; Tue, 01 Sep 2015 20:19:31 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NU000G9MDGI0W50@HIDDEN>; Tue, 01 Sep 2015 20:19:31 +0300 (IDT)
Date: Tue, 01 Sep 2015 20:19:25 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#21380: 25.0.50;
 GTK-induced segfault when scheduling timer from
 window-configuration-change-hook
In-reply-to: <CAOqdjBdiYySbRS4xvVfK2zx+KiSskJOwHEZK7=t_gwP3Wqm+4g@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Pip Cet <pipcet@HIDDEN>
Message-id: <83vbbuawgy.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
 <83a8t71qct.fsf@HIDDEN>
 <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
 <CAOqdjBfy8KdZnNSB5NBdwkYk=AMG9MMezyGgH06yM5S=Q35Fcw@HIDDEN>
 <837foaceid.fsf@HIDDEN>
 <CAOqdjBdiYySbRS4xvVfK2zx+KiSskJOwHEZK7=t_gwP3Wqm+4g@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Tue, 1 Sep 2015 16:56:04 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: 21380 <at> debbugs.gnu.org
> 
> > 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?)

I meant atimers, sorry for being unclear.  See process_pending_signals.

> The only code path that I see that's potentially dangerous is that atimers
> appear to be executed even if input is blocked.

Yes, that's exactly what bothered me.  Not calling QUIT prevents that.

Alternatively, we could turn off atimers (by calling turn_on_atimers)
while Fcopy_sequence runs.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 16:56:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 01 12:56:08 2015
Received: from localhost ([127.0.0.1]:45307 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZWoqu-0008Sn-1L
	for submit <at> debbugs.gnu.org; Tue, 01 Sep 2015 12:56:08 -0400
Received: from mail-ig0-f175.google.com ([209.85.213.175]:33720)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZWoqr-0008Sf-OU
 for 21380 <at> debbugs.gnu.org; Tue, 01 Sep 2015 12:56:06 -0400
Received: by igbkq10 with SMTP id kq10so5843985igb.0
 for <21380 <at> 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==
MIME-Version: 1.0
X-Received: by 10.50.112.227 with SMTP id it3mr3598288igb.93.1441126564865;
 Tue, 01 Sep 2015 09:56:04 -0700 (PDT)
Received: by 10.79.78.66 with HTTP; Tue, 1 Sep 2015 09:56:04 -0700 (PDT)
In-Reply-To: <837foaceid.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
 <83a8t71qct.fsf@HIDDEN>
 <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
 <CAOqdjBfy8KdZnNSB5NBdwkYk=AMG9MMezyGgH06yM5S=Q35Fcw@HIDDEN>
 <837foaceid.fsf@HIDDEN>
Date: Tue, 1 Sep 2015 16:56:04 +0000
Message-ID: <CAOqdjBdiYySbRS4xvVfK2zx+KiSskJOwHEZK7=t_gwP3Wqm+4g@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=089e0102f83ef9abc7051eb26cee
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--089e0102f83ef9abc7051eb26cee
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 1, 2015 at 4:04 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > Date: Tue, 1 Sep 2015 15:14:09 +0000
> > From: Pip Cet <pipcet@HIDDEN>
> > Cc: 21380 <at> 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

<div dir=3D"ltr">On Tue, Sep 1, 2015 at 4:04 PM, Eli Zaretskii <span dir=3D=
"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a=
>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; Date: Tue, 1 Sep 2=
015 15:14:09 +0000<br>
<span class=3D"">&gt; From: Pip Cet &lt;<a href=3D"mailto:pipcet@HIDDEN"=
>pipcet@HIDDEN</a>&gt;<br>
&gt; Cc: <a href=3D"mailto:21380 <at> debbugs.gnu.org">21380 <at> debbugs.gnu.org</a>=
<br>
&gt;<br>
</span><span class=3D"">&gt; (* - well, one segfault. But I attribute that =
to extraordinarily bizarre<br>
&gt; actions even by my standards: attempting to display an unprintable ASC=
II<br>
&gt; control character in the echo area.<br>
<br>
</span>Is this reproducible?=C2=A0 If so, please submit a separate bug repo=
rt with<br>
a recipe.<br></blockquote><div><br>#21394.<br></div>=C2=A0<blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<span class=3D"">
&gt; Usually this is fine because propertized strings never end up in the<b=
r>
&gt; echo area (I hope)...)<br>
<br>
</span>The echo area is a normal buffer, so any face can be used in it.=C2=
=A0 See,<br>
for example, the message printed by info.el after &quot;i SOMETHING RET&quo=
t;.<br>
</blockquote></div><br></div><div class=3D"gmail_extra">Thanks for explaini=
ng! You&#39;re right, then, it&#39;s a bug.<br></div><div class=3D"gmail_ex=
tra"><br>&gt; That only prevents us from reading new events from the X sock=
et, but<br>&gt; what if some signal that is already pending invokes some Li=
sp?<br><br></div><div class=3D"gmail_extra">I don&#39;t understand. How can=
 we call &quot;some signal that is already pending&quot; (I&#39;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&#39;t call any Lisp.<br><br></div><div class=3D"gmail_extra">The o=
nly code path that I see that&#39;s potentially dangerous is that atimers a=
ppear to be executed even if input is blocked.<br></div></div>

--089e0102f83ef9abc7051eb26cee--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 16:23:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 01 12:23:30 2015
Received: from localhost ([127.0.0.1]:45272 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZWoLK-0007hC-GG
	for submit <at> debbugs.gnu.org; Tue, 01 Sep 2015 12:23:30 -0400
Received: from mtaout24.012.net.il ([80.179.55.180]:57916)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1ZWoLI-0007h3-88
 for 21380 <at> debbugs.gnu.org; Tue, 01 Sep 2015 12:23:29 -0400
Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il
 (HyperSendmail v2007.08) id <0NU000300A93KU00@HIDDEN> for
 21380 <at> debbugs.gnu.org; Tue, 01 Sep 2015 19:15:39 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout24.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NU000MF2AI3TY80@HIDDEN>; Tue, 01 Sep 2015 19:15:39 +0300 (IDT)
Date: Tue, 01 Sep 2015 19:23:38 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#21380: 25.0.50;
 GTK-induced segfault when scheduling timer from
 window-configuration-change-hook
In-reply-to: <CAOqdjBe-6sEzp5CBhz77e8u=rDhsbJUQTqJmPjOW6bYAt6BtJA@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Pip Cet <pipcet@HIDDEN>
Message-id: <831teicdmd.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
 <83a8t71qct.fsf@HIDDEN>
 <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
 <83fv2ychbg.fsf@HIDDEN>
 <CAOqdjBcNADPXuC+kXe5r0GmOk_i+xmnmwBJU2NhTb7sDVOsLXg@HIDDEN>
 <838u8qcenv.fsf@HIDDEN>
 <CAOqdjBe-6sEzp5CBhz77e8u=rDhsbJUQTqJmPjOW6bYAt6BtJA@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Tue, 1 Sep 2015 16:02:59 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: 21380 <at> debbugs.gnu.org
> 
> On Tue, Sep 1, 2015 at 4:01 PM, Eli Zaretskii <eliz@HIDDEN> wrote:
> 
>     So maybe we should introduce a special copy_sequence_no_quit function
>     that never calls QUIT, and then use it for copying the timer lists.
> 
> How would that be different from calling block_input () and binding
> Vinhibit_quit around the call to copy_sequence?

That only prevents us from reading new events from the X socket, but
what if some signal that is already pending invokes some Lisp?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 16:04:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 01 12:04:19 2015
Received: from localhost ([127.0.0.1]:45260 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZWo2l-0007Go-HT
	for submit <at> debbugs.gnu.org; Tue, 01 Sep 2015 12:04:19 -0400
Received: from mtaout21.012.net.il ([80.179.55.169]:50514)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1ZWo2i-0007Ge-GJ
 for 21380 <at> debbugs.gnu.org; Tue, 01 Sep 2015 12:04:18 -0400
Received: from conversion-daemon.a-mtaout21.012.net.il by
 a-mtaout21.012.net.il (HyperSendmail v2007.08) id
 <0NU000G009UBUZ00@HIDDEN> for 21380 <at> debbugs.gnu.org;
 Tue, 01 Sep 2015 19:04:15 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NU000G879Z2UD20@HIDDEN>;
 Tue, 01 Sep 2015 19:04:15 +0300 (IDT)
Date: Tue, 01 Sep 2015 19:04:26 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#21380: 25.0.50;
 GTK-induced segfault when scheduling timer from
 window-configuration-change-hook
In-reply-to: <CAOqdjBfy8KdZnNSB5NBdwkYk=AMG9MMezyGgH06yM5S=Q35Fcw@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Pip Cet <pipcet@HIDDEN>
Message-id: <837foaceid.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
 <83a8t71qct.fsf@HIDDEN>
 <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
 <CAOqdjBfy8KdZnNSB5NBdwkYk=AMG9MMezyGgH06yM5S=Q35Fcw@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Tue, 1 Sep 2015 15:14:09 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: 21380 <at> 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.

> It seems we never make sure that
> non-standard faces are cached when redisplaying the echo area.

I don't see how this can happen, since the face cache is per-frame,
not per-window or buffer.

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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 16:03:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 01 12:03:08 2015
Received: from localhost ([127.0.0.1]:45256 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZWo1b-0007F5-Ke
	for submit <at> debbugs.gnu.org; Tue, 01 Sep 2015 12:03:08 -0400
Received: from mail-ig0-f173.google.com ([209.85.213.173]:34802)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZWo1W-0007Ev-BF
 for 21380 <at> debbugs.gnu.org; Tue, 01 Sep 2015 12:03:06 -0400
Received: by igcpb10 with SMTP id pb10so4627307igc.1
 for <21380 <at> debbugs.gnu.org>; Tue, 01 Sep 2015 09:03:01 -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=lpLfFMzsu6hwGgmB7RF8hsc/r26tELZGYw9T5yO4wvs=;
 b=cRv1IYwkn7olAIMaGcOc/U4WLKpkKrTM9trj8RktOhMRBzaPwUzfBxb8WDPL29E2te
 XV94P0aP71XPWd+J/181/TUZfC/3bnqFCU4Z4ykxcml9jZidjDCRKp6XYhN1tucVMtcK
 JZUCkt8CF9+nbE9uNm1PfUyNDficsPA1sjJANqxahxRS1ku7dZBI8mEcIpxrx09EWFo3
 mzZEjR9DTnviNfx7owsqdMZwyKLixxM2qJnXG46eq1fN2jqrtsOtY0dngDT3N90aGOZR
 ZgdK23GqEPjeTxoQRo7OBohmuJG/ET0vL+nZ1MGVXrNe4AFYtulg6IrZyhNzAU7JHlAM
 S7yA==
MIME-Version: 1.0
X-Received: by 10.50.97.33 with SMTP id dx1mr3065315igb.1.1441123379669; Tue,
 01 Sep 2015 09:02:59 -0700 (PDT)
Received: by 10.79.78.66 with HTTP; Tue, 1 Sep 2015 09:02:59 -0700 (PDT)
In-Reply-To: <838u8qcenv.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
 <83a8t71qct.fsf@HIDDEN>
 <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
 <83fv2ychbg.fsf@HIDDEN>
 <CAOqdjBcNADPXuC+kXe5r0GmOk_i+xmnmwBJU2NhTb7sDVOsLXg@HIDDEN>
 <838u8qcenv.fsf@HIDDEN>
Date: Tue, 1 Sep 2015 16:02:59 +0000
Message-ID: <CAOqdjBe-6sEzp5CBhz77e8u=rDhsbJUQTqJmPjOW6bYAt6BtJA@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=047d7b10c8891f73ab051eb1afa7
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--047d7b10c8891f73ab051eb1afa7
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 1, 2015 at 4:01 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> So maybe we should introduce a special copy_sequence_no_quit function
> that never calls QUIT, and then use it for copying the timer lists.
>

How would that be different from calling block_input () and binding
Vinhibit_quit around the call to copy_sequence?

--047d7b10c8891f73ab051eb1afa7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Sep 1, 2015 at 4:01 PM, Eli Zaretskii <span dir=3D=
"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a=
>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><span class=3D"">
</span>So maybe we should introduce a special copy_sequence_no_quit functio=
n<br>
that never calls QUIT, and then use it for copying the timer lists.<br></bl=
ockquote><div><br></div><div>How would that be different from calling block=
_input () and binding Vinhibit_quit around the call to copy_sequence?<br></=
div></div></div></div>

--047d7b10c8891f73ab051eb1afa7--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 16:01:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 01 12:01:08 2015
Received: from localhost ([127.0.0.1]:45252 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZWnzc-0007CB-Bq
	for submit <at> debbugs.gnu.org; Tue, 01 Sep 2015 12:01:08 -0400
Received: from mtaout29.012.net.il ([80.179.55.185]:46915)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1ZWnzW-0007Bb-Gr
 for 21380 <at> debbugs.gnu.org; Tue, 01 Sep 2015 12:01:02 -0400
Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il
 (HyperSendmail v2007.08) id <0NU000O009TYTX00@HIDDEN> for
 21380 <at> debbugs.gnu.org; Tue, 01 Sep 2015 19:01:15 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NU000OBZ9U2IO00@HIDDEN>; Tue, 01 Sep 2015 19:01:15 +0300 (IDT)
Date: Tue, 01 Sep 2015 19:01:08 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#21380: 25.0.50;
 GTK-induced segfault when scheduling timer from
 window-configuration-change-hook
In-reply-to: <CAOqdjBcNADPXuC+kXe5r0GmOk_i+xmnmwBJU2NhTb7sDVOsLXg@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Pip Cet <pipcet@HIDDEN>
Message-id: <838u8qcenv.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
 <83a8t71qct.fsf@HIDDEN>
 <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
 <83fv2ychbg.fsf@HIDDEN>
 <CAOqdjBcNADPXuC+kXe5r0GmOk_i+xmnmwBJU2NhTb7sDVOsLXg@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Tue, 1 Sep 2015 15:22:58 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: 21380 <at> debbugs.gnu.org
> 
>     Or am I missing something? I thought you
>     intended to recalculate the length on each iteration?
> 
> If you can think of a good way of doing that, I'd be grateful. I can't, because
> Flength calls QUIT, too, so there's no guarantee its results are still valid
> when it's done.
> 
> All we could do, as far as I can see, is add an extra call to Flength() which
> will slow things down and sometimes but not always make the risky thing the
> user is attempting work. Other than that, a non-segfault with an incorrect
> result is all we can give the user, I fear.

So maybe we should introduce a special copy_sequence_no_quit function
that never calls QUIT, and then use it for copying the timer lists.
Timer lists are never too long, so that shouldn't be a problem.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 15:23:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 01 11:23:01 2015
Received: from localhost ([127.0.0.1]:45229 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZWnOn-0006IC-5r
	for submit <at> debbugs.gnu.org; Tue, 01 Sep 2015 11:23:01 -0400
Received: from mail-qk0-f179.google.com ([209.85.220.179]:35412)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZWnOl-0006I3-ID
 for 21380 <at> debbugs.gnu.org; Tue, 01 Sep 2015 11:23:00 -0400
Received: by qkcj187 with SMTP id j187so45013272qkc.2
 for <21380 <at> debbugs.gnu.org>; Tue, 01 Sep 2015 08:22:59 -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=t1zfl2Y4ibimDDScJ2QMynn2QQBRAkPUDQvPT3bbjg4=;
 b=LhCBAQre7zr33VHEN8YItex61QfzPZj0XutRdsaIQcyOqD6B/XHDDEdhSlvVEl90de
 NaViKzYTkuGYdb/U788QmvdWQp+UNdMKO3/up8JPTriZWNDpAsgqKdZ3cVAkYHWYb+9J
 pVp51uEqNqyPIgnqcNB00y2mVyZ0s5uPkzNNdNAcIt/dsf/ESC51kLQMcqIKdTjno2QV
 5NjWh+RWW39Ax4XqHLTgP/AkF9i6B/qqlnB1aBKowHhExTeGQyOeUEUYVqzGBsEmupxc
 2FIe5TaK4spEnErMxgDVp1RblRSbY8bEEq014eVnEw2zCL99H5ePVIt4yU/L48sxAqZ2
 YTKw==
MIME-Version: 1.0
X-Received: by 10.13.202.66 with SMTP id m63mr27883858ywd.127.1441120978861;
 Tue, 01 Sep 2015 08:22:58 -0700 (PDT)
Received: by 10.37.74.200 with HTTP; Tue, 1 Sep 2015 08:22:58 -0700 (PDT)
In-Reply-To: <83fv2ychbg.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
 <83a8t71qct.fsf@HIDDEN>
 <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
 <83fv2ychbg.fsf@HIDDEN>
Date: Tue, 1 Sep 2015 15:22:58 +0000
Message-ID: <CAOqdjBcNADPXuC+kXe5r0GmOk_i+xmnmwBJU2NhTb7sDVOsLXg@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11481518060701051eb12022
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a11481518060701051eb12022
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 1, 2015 at 3:03 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > Date: Tue, 1 Sep 2015 10:20:11 +0000
> > From: Pip Cet <pipcet@HIDDEN>
> > Cc: 21380 <at> debbugs.gnu.org
> >
> >     Can you show a patch that fixes the original segfault in your use
> >     case?
> >
> > Attached.
>
> Hmm... isn't that a kludge?
>

It is. It replaces segfaults by incorrect results.

Or am I missing something?  I thought you
> intended to recalculate the length on each iteration?
>

If you can think of a good way of doing that, I'd be grateful. I can't,
because Flength calls QUIT, too, so there's no guarantee its results are
still valid when it's done.

All we could do, as far as I can see, is add an extra call to Flength()
which will slow things down and sometimes but not always make the risky
thing the user is attempting work. Other than that, a non-segfault with an
incorrect result is all we can give the user, I fear.

--001a11481518060701051eb12022
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Sep 1, 2015 at 3:03 PM, Eli Zaretskii <span dir=3D=
"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a=
>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div>&gt; Date: Tue, 1 =
Sep 2015 10:20:11 +0000<br>
<span>&gt; From: Pip Cet &lt;<a href=3D"mailto:pipcet@HIDDEN" target=3D"=
_blank">pipcet@HIDDEN</a>&gt;<br>
&gt; Cc: <a href=3D"mailto:21380 <at> debbugs.gnu.org" target=3D"_blank">21380@d=
ebbugs.gnu.org</a><br>
&gt;<br>
</span></div><span>&gt;=C2=A0 =C2=A0 =C2=A0Can you show a patch that fixes =
the original segfault in your use<br></span><div><div><span>
&gt;=C2=A0 =C2=A0 =C2=A0case?<br>
&gt;<br>
&gt; Attached.<br>
<br>
</span>Hmm... isn&#39;t that a kludge?</div></div></blockquote><div><br></d=
iv><div>It is. It replaces segfaults by incorrect results.<br></div><div><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"> Or am I missing something?=C2=A0 I =
thought you<br>
intended to recalculate the length on each iteration?<br></blockquote><div>=
<br></div><div>If you can think of a good way of doing that, I&#39;d be gra=
teful. I can&#39;t, because Flength calls QUIT, too, so there&#39;s no guar=
antee its results are still valid when it&#39;s done.<br></div><div><br></d=
iv><div>All we could do, as far as I can see, is add an extra call to Fleng=
th() which will slow things down and sometimes but not always make the risk=
y thing the user is attempting work. Other than that, a non-segfault with a=
n incorrect result is all we can give the user, I fear.<br></div></div></di=
v></div>

--001a11481518060701051eb12022--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 15:14:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 01 11:14:16 2015
Received: from localhost ([127.0.0.1]:45225 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZWnGJ-00066G-8z
	for submit <at> debbugs.gnu.org; Tue, 01 Sep 2015 11:14:16 -0400
Received: from mail-io0-f170.google.com ([209.85.223.170]:35121)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZWnGG-000663-Cs
 for 21380 <at> debbugs.gnu.org; Tue, 01 Sep 2015 11:14:13 -0400
Received: by ioiz6 with SMTP id z6so4531011ioi.2
 for <21380 <at> debbugs.gnu.org>; Tue, 01 Sep 2015 08:14:11 -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=y8yohLojjDk7OJqePZTgBsjwQolYnFaUAJtC9GdlwU8=;
 b=eWcoYvO894P75tjzIYh9kkA3ETNdjDhQEeUB9i78AGKcVflUKqyDHFgSRA5uTrBYNh
 Cj0zQBWNa7KNzYbcKagrylX0jwYyrSXCR7zUfzjbi7VOHgAcw9NIk3dDRg5PuU/qjLoD
 TYl5fdolrLIvR4AW/ek91UKyyrlQGEcQ73XpL9Swp2VOdr/bPZ43f20/Z5/BJvV32wjq
 CneSWzeVil8HeMIeMOVSDbLOUR/mCd0C/qb3y21/hNwlsIn+YXkgjy+Nuzg19S0kokNQ
 2pggilKVygtmQRAuM8p95qA+sfTgM5bF4EZ4oTpq/NdHSaKhftSVuN/Da0WdfqVGmQyY
 gwNg==
MIME-Version: 1.0
X-Received: by 10.107.47.97 with SMTP id j94mr30020429ioo.136.1441120450292;
 Tue, 01 Sep 2015 08:14:10 -0700 (PDT)
Received: by 10.79.78.66 with HTTP; Tue, 1 Sep 2015 08:14:09 -0700 (PDT)
In-Reply-To: <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
 <83a8t71qct.fsf@HIDDEN>
 <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
Date: Tue, 1 Sep 2015 15:14:09 +0000
Message-ID: <CAOqdjBfy8KdZnNSB5NBdwkYk=AMG9MMezyGgH06yM5S=Q35Fcw@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/mixed; boundary=001a1144ac34852304051eb10037
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a1144ac34852304051eb10037
Content-Type: multipart/alternative; boundary=001a1144ac34852300051eb10035

--001a1144ac34852300051eb10035
Content-Type: text/plain; charset=UTF-8

No segfault*.

(* - 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. It seems we never make sure that
non-standard faces are cached when redisplaying the echo area. Usually this
is fine because propertized strings never end up in the echo area (I
hope)...)

Revised patch attached (use NILP, fix bug number in changelog entry).


On Tue, Sep 1, 2015 at 10:20 AM, Pip Cet <pipcet@HIDDEN> wrote:

> On Mon, Aug 31, 2015 at 2:31 PM, Eli Zaretskii <eliz@HIDDEN> wrote:
>
>> > Yes for this particular segfault.
>>
>> Can you show a patch that fixes the original segfault in your use
>> case?
>
>
> Attached. Note that either one of those changes should work. I'll test
> this patch some more using my original code and see whether it blows up.
>
> I'm afraid I lost track, what with all the different scenarios
>> and potential solutions being thrown at this.  We should install the
>> fix, assuming it's clean.
>>
>
> I think we should fix three things:
>  - concat shouldn't rely on its argument remaining unchanged in length
>  - the timer list copy should happen with block_input/unblock_input
> wrapped around it
>  - we shouldn't call do_pending_window_change from QUIT [already
> installed. Thanks, martin!]
>
> Any one of these is enough to prevent the original segfault. All but the
> second also prevent the bizarre-elisp-induced segfault I came up with
> later. And I'm perfectly happy for today with the number of hooks called
> from QUIT reduced by one, rather than insisting on reducing them to zero
> right away.
>
> > No* for similar segfaults that I think pose equally severe problems: if
>> any other function calls concat/copy-sequence on data that is modified by
>> window-configuration-change-hook, it should* still be possible to produce
>> the segfault.
>>
>> Emacs gives you enough rope to hang yourself; there's nothing new
>> here.  We should strive to protect the Emacs internals so that they
>> won't cause segfaults, but in user code any bets are off, and "don't
>> do that" is a valid response to whoever does such things.
>>
>
> It's always good to know what the philosophy is behind the way the code
> works, so thank you for that, really.
>
> > So it wouldn't even be safe for window-configuration-change-hook to add
>> a timer to the timer list, because the outer frame might be in the middle
>> of creating a copy of the timer list for some Lisp code that hasn't blocked
>> input. (As in my example below)
>>
>> Futzing with timers from within some hooks is indeed fundamentally
>> dangerous.
>
>
> Well, doing anything from window-configuration-change-hook is dangerous.
> My idea was to schedule an immediate timer from it to get out of the danger
> zone to do the actual work, but that backfired...
>
>
>> But we should still try to minimize the probability of a
>> crash, especially when it's Emacs itself who makes the offending copy,
>> because people do dangerous things all the time, and expect them to
>> work.  In this case, blocking input should do, I think.
>>
>
> I agree.
>
> > I really don't think QUIT should run any Lisp hooks, to be honest.
>>
>> I don't think this limitation could fly.  It will disable a lot of
>> useful use patterns, and the outcry will be loud and clear.
>>
>
> Okay.
>
> > If I'm wrong and QUIT should be able to run Lisp hooks, concat needs to
>> be fixed not to rely on its argument's size being unchanged after the
>> make_sequence call.
>>
>> That can't do any harm, so let's do it, too.
>>
>
> Cool.
>
>
>> > As far as I can tell, that should be reproducible. Also as far as I can
>> tell, it's merely a matter of luck that an X resize doesn't happen at the
>> point where I interrupted the program to artificially trigger the segfault.
>> However, I admit that it is a separate issue, less likely to occur in
>> practice, and I'll open another bug for it if that's the way you prefer
>> things.
>>
>> But if input is blocked, as it would be in the case of copying
>> timer-list inside timer_check, the X events will not be acted upon,
>> and the problem will not happen, right?
>>
>
> Indeed, that relies on bizarre elisp code deliberately doing silly
> things...
>
>
>> IOW, the above situation is a case of a user shooting herself in the
>> foot by having that particular function in the hook and that
>> particular code that copies timer-list (which is an internal variable
>> unwise users should not touch).  Am I right?
>>
>
> I think you are. I'm not sure whether the timer code in timer.el does
> anything to the timer list that might count as dangerous, but that's
> possibly the only legitimate Lisp user of timer-list.
>

--001a1144ac34852300051eb10035
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>No segfault*.<br><br>(* - well, one segfault. But I a=
ttribute that to extraordinarily bizarre actions even by my standards: atte=
mpting to display an unprintable ASCII control character in the echo area. =
It seems we never make sure that non-standard faces are cached when redispl=
aying the echo area. Usually this is fine because propertized strings never=
 end up in the echo area (I hope)...)<br><br></div><div>Revised patch attac=
hed (use NILP, fix bug number in changelog entry).<br></div><div><br></div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Sep=
 1, 2015 at 10:20 AM, Pip Cet <span dir=3D"ltr">&lt;<a href=3D"mailto:pipce=
t@HIDDEN" target=3D"_blank">pipcet@HIDDEN</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Mon, Aug =
31, 2015 at 2:31 PM, Eli Zaretskii <span dir=3D"ltr">&lt;<a href=3D"mailto:=
eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>&gt;</span> wrote:<br></spa=
n><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><span>&gt; Yes for this particular segfault.<b=
r>
<br>
</span>Can you show a patch that fixes the original segfault in your use<br=
>
case?</blockquote><div><br></div></span><div>Attached. Note that either one=
 of those changes should work. I&#39;ll test this patch some more using my =
original code and see whether it blows up.<br><br></div><span class=3D""><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"> I&#39;m afraid I lost track, what with all th=
e different scenarios<br>
and potential solutions being thrown at this.=C2=A0 We should install the<b=
r>
fix, assuming it&#39;s clean.<br></blockquote><div><br></div></span><div>I =
think we should fix three things:<br></div><div>=C2=A0- concat shouldn&#39;=
t rely on its argument remaining unchanged in length<br></div><div>=C2=A0- =
the timer list copy should happen with block_input/unblock_input wrapped ar=
ound it<br></div><div>=C2=A0- we shouldn&#39;t call do_pending_window_chang=
e from QUIT [already installed. Thanks, martin!]<br><br></div><div>Any one =
of these is enough to prevent the original segfault. All but the second als=
o prevent the bizarre-elisp-induced segfault I came up with later. And I&#3=
9;m perfectly happy for today with the number of hooks called from QUIT red=
uced by one, rather than insisting on reducing them to zero right away.<br>=
<br></div><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span>
&gt; No* for similar segfaults that I think pose equally severe problems: i=
f any other function calls concat/copy-sequence on data that is modified by=
 window-configuration-change-hook, it should* still be possible to produce =
the segfault.<br>
<br>
</span>Emacs gives you enough rope to hang yourself; there&#39;s nothing ne=
w<br>
here.=C2=A0 We should strive to protect the Emacs internals so that they<br=
>
won&#39;t cause segfaults, but in user code any bets are off, and &quot;don=
&#39;t<br>
do that&quot; is a valid response to whoever does such things.<br></blockqu=
ote><div><br></div></span><div>It&#39;s always good to know what the philos=
ophy is behind the way the code works, so thank you for that, really.<br><b=
r></div><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span>
&gt; So it wouldn&#39;t even be safe for window-configuration-change-hook t=
o add a timer to the timer list, because the outer frame might be in the mi=
ddle of creating a copy of the timer list for some Lisp code that hasn&#39;=
t blocked input. (As in my example below)<br>
<br>
</span>Futzing with timers from within some hooks is indeed fundamentally<b=
r>
dangerous.</blockquote><div><br></div></span><div>Well, doing anything from=
 window-configuration-change-hook is dangerous. My idea was to schedule an =
immediate timer from it to get out of the danger zone to do the actual work=
, but that backfired...<br></div><span class=3D""><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"> But we should still try to minimize the probability=
 of a<br>
crash, especially when it&#39;s Emacs itself who makes the offending copy,<=
br>
because people do dangerous things all the time, and expect them to<br>
work.=C2=A0 In this case, blocking input should do, I think.<br></blockquot=
e><div><br></div></span><div>I agree.<br></div><span class=3D""><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<span>
&gt; I really don&#39;t think QUIT should run any Lisp hooks, to be honest.=
<br>
<br>
</span>I don&#39;t think this limitation could fly.=C2=A0 It will disable a=
 lot of<br>
useful use patterns, and the outcry will be loud and clear.<br></blockquote=
><br></span></div><div class=3D"gmail_quote">Okay.<br></div><div class=3D"g=
mail_quote"><span class=3D""><br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span>
&gt; If I&#39;m wrong and QUIT should be able to run Lisp hooks, concat nee=
ds to be fixed not to rely on its argument&#39;s size being unchanged after=
 the make_sequence call.<br>
<br>
</span>That can&#39;t do any harm, so let&#39;s do it, too.<span><br></span=
></blockquote><div><br></div></span><div>Cool.<br></div><span class=3D""><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><span>
&gt; As far as I can tell, that should be reproducible. Also as far as I ca=
n tell, it&#39;s merely a matter of luck that an X resize doesn&#39;t happe=
n at the point where I interrupted the program to artificially trigger the =
segfault. However, I admit that it is a separate issue, less likely to occu=
r in practice, and I&#39;ll open another bug for it if that&#39;s the way y=
ou prefer things.<br>
<br>
</span>But if input is blocked, as it would be in the case of copying<br>
timer-list inside timer_check, the X events will not be acted upon,<br>
and the problem will not happen, right?<br></blockquote><br></span></div><d=
iv class=3D"gmail_quote">Indeed, that relies on bizarre elisp code delibera=
tely doing silly things...<br></div><span class=3D""><div class=3D"gmail_qu=
ote"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

IOW, the above situation is a case of a user shooting herself in the<br>
foot by having that particular function in the hook and that<br>
particular code that copies timer-list (which is an internal variable<br>
unwise users should not touch).=C2=A0 Am I right?<br>
</blockquote></div><br></span></div><div class=3D"gmail_extra">I think you =
are. I&#39;m not sure whether the timer code in timer.el does anything to t=
he timer list that might count as dangerous, but that&#39;s possibly the on=
ly legitimate Lisp user of timer-list.<br></div></div>
</blockquote></div><br></div>

--001a1144ac34852300051eb10035--
--001a1144ac34852304051eb10037
Content-Type: text/x-patch; charset=US-ASCII; 
	name="0001-Fix-potential-race-conditions-Bug-21380.patch"
Content-Disposition: attachment; 
	filename="0001-Fix-potential-race-conditions-Bug-21380.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_ie1hwtdn0

RnJvbSA3ZGM4YzlkN2E0OTk3NzgxYzA0MDAxMzcxYWMzODRkYjI0YzM3ZTU5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXAgPHBpcGNldEBnbWFpbC5jb20+CkRhdGU6IFR1ZSwg
MSBTZXAgMjAxNSAxMDoxMjozMSArMDAwMApTdWJqZWN0OiBbUEFUQ0hdIEZpeCBwb3RlbnRpYWwg
cmFjZSBjb25kaXRpb25zIChCdWcjMjEzODApCgogICAgICAgICoga2V5Ym9hcmQuYyAodGltZXJf
Y2hlY2spOiBDYWxsIGBibG9ja19pbnB1dCcgYXJvdW5kIHRoZSBjcmVhdGlvbgoJb2YgdGhlIHRl
bXBvcmFyeSB0aW1lciBsaXN0IGNvcHkuCgoJKiBmbnMuYyAoY29uY2F0KTogRG9uJ3QgYXNzdW1l
IGFyZ3VtZW50IHNpemUgcmVtYWlucyB1bmNoYW5nZWQKCWFmdGVyIGNhbGwgdG8gYEZtYWtlX2xp
c3QnLgotLS0KIHNyYy9mbnMuYyAgICAgIHwgMyArKysKIHNyYy9rZXlib2FyZC5jIHwgMiArKwog
MiBmaWxlcyBjaGFuZ2VkLCA1IGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9zcmMvZm5zLmMg
Yi9zcmMvZm5zLmMKaW5kZXggMjZhOThhYi4uMTVkOWU2NCAxMDA2NDQKLS0tIGEvc3JjL2Zucy5j
CisrKyBiL3NyYy9mbnMuYwpAQCAtNzQ0LDYgKzc0NCw5IEBAIGNvbmNhdCAocHRyZGlmZl90IG5h
cmdzLCBMaXNwX09iamVjdCAqYXJncywKIAkgICAgLyogU3RvcmUgdGhpcyBlbGVtZW50IGludG8g
dGhlIHJlc3VsdC4gICovCiAJICAgIGlmICh0b2luZGV4IDwgMCkKIAkgICAgICB7CisgICAgICAg
ICAgICAgICAgaWYgKE5JTFAgKHRhaWwpKQorICAgICAgICAgICAgICAgICAgYnJlYWs7CisKIAkJ
WFNFVENBUiAodGFpbCwgZWx0KTsKIAkJcHJldiA9IHRhaWw7CiAJCXRhaWwgPSBYQ0RSICh0YWls
KTsKZGlmZiAtLWdpdCBhL3NyYy9rZXlib2FyZC5jIGIvc3JjL2tleWJvYXJkLmMKaW5kZXggZGFi
MzJiMS4uNGI3ZDY3NSAxMDA2NDQKLS0tIGEvc3JjL2tleWJvYXJkLmMKKysrIGIvc3JjL2tleWJv
YXJkLmMKQEAgLTQ1NjAsNiArNDU2MCw3IEBAIHRpbWVyX2NoZWNrICh2b2lkKQogCiAgIExpc3Bf
T2JqZWN0IHRlbSA9IFZpbmhpYml0X3F1aXQ7CiAgIFZpbmhpYml0X3F1aXQgPSBRdDsKKyAgYmxv
Y2tfaW5wdXQgKCk7CiAKICAgLyogV2UgdXNlIGNvcGllcyBvZiB0aGUgdGltZXJzJyBsaXN0cyB0
byBhbGxvdyBhIHRpbWVyIHRvIGFkZCBpdHNlbGYKICAgICAgYWdhaW4sIHdpdGhvdXQgbG9ja2lu
ZyB1cCBFbWFjcyBpZiB0aGUgbmV3bHkgYWRkZWQgdGltZXIgaXMKQEAgLTQ1NzMsNiArNDU3NCw3
IEBAIHRpbWVyX2NoZWNrICh2b2lkKQogICBlbHNlCiAgICAgaWRsZV90aW1lcnMgPSBRbmlsOwog
CisgIHVuYmxvY2tfaW5wdXQgKCk7CiAgIFZpbmhpYml0X3F1aXQgPSB0ZW07CiAKICAgZG8KLS0g
CjIuNS4wCgo=
--001a1144ac34852304051eb10037--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 15:03:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 01 11:03:47 2015
Received: from localhost ([127.0.0.1]:45214 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZWn67-0005rP-Ou
	for submit <at> debbugs.gnu.org; Tue, 01 Sep 2015 11:03:47 -0400
Received: from mtaout27.012.net.il ([80.179.55.183]:41461)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1ZWn61-0005rB-LV
 for 21380 <at> debbugs.gnu.org; Tue, 01 Sep 2015 11:03:41 -0400
Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il
 (HyperSendmail v2007.08) id <0NU000F006OIBH00@HIDDEN> for
 21380 <at> debbugs.gnu.org; Tue, 01 Sep 2015 18:00:23 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NU000AP670NGP60@HIDDEN>; Tue, 01 Sep 2015 18:00:23 +0300 (IDT)
Date: Tue, 01 Sep 2015 18:03:47 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#21380: 25.0.50;
 GTK-induced segfault when scheduling timer from
 window-configuration-change-hook
In-reply-to: <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Pip Cet <pipcet@HIDDEN>
Message-id: <83fv2ychbg.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
 <83a8t71qct.fsf@HIDDEN>
 <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Tue, 1 Sep 2015 10:20:11 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: 21380 <at> debbugs.gnu.org
> 
>     Can you show a patch that fixes the original segfault in your use
>     case?
> 
> Attached.

Hmm... isn't that a kludge?  Or am I missing something?  I thought you
intended to recalculate the length on each iteration?

> I think we should fix three things:
> - concat shouldn't rely on its argument remaining unchanged in length
> - the timer list copy should happen with block_input/unblock_input wrapped
> around it
> - we shouldn't call do_pending_window_change from QUIT [already installed.
> Thanks, martin!]
> 
> Any one of these is enough to prevent the original segfault. All but the second
> also prevent the bizarre-elisp-induced segfault I came up with later.

I think we should make all of these changes.

> I'm not sure whether the timer code in timer.el does anything to the
> timer list that might count as dangerous, but that's possibly the
> only legitimate Lisp user of timer-list.

Indeed.  And if it does something unsafe, we should fix that.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 10:20:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 01 06:20:16 2015
Received: from localhost ([127.0.0.1]:44740 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZWifn-0005m5-5h
	for submit <at> debbugs.gnu.org; Tue, 01 Sep 2015 06:20:16 -0400
Received: from mail-io0-f172.google.com ([209.85.223.172]:34196)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZWifk-0005lx-8E
 for 21380 <at> debbugs.gnu.org; Tue, 01 Sep 2015 06:20:13 -0400
Received: by ioeu67 with SMTP id u67so47704972ioe.1
 for <21380 <at> debbugs.gnu.org>; Tue, 01 Sep 2015 03:20:11 -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=ae8wfFBO0pfhuzv4f6+mJzu9qyEfMZnP2nsbuIq4p8c=;
 b=SwhvPfFerZIA/HxgED4y3aX2bC0ctPEE1MyGq5F/Esld7MEvAsBxQjFAFeK0SLXzTC
 vu+GkhzjogEmDf6roP8RFGhS/zVnigURh6BrF2HehPXrA4U82gLJxxEfn5HkkG5oMuZN
 ayKg0j9DgPAyWGw8sBzimPrABSM9YRT0FnaXo1s5p8lZLfi8brcF6tysw3oL2Vx8Bffv
 VrFaNo+knXn957ROFCe0A1XpD3I1maIa2Xg04HOEIss05eHRR8+CCEexO0kp9DB9ZiY1
 SUpeQX+AFfISDGL96msVgXf13UTrDAe1nnU8yW/JnhYt2rDbLZAZ/DfGobceyi3U9gh0
 uxzQ==
MIME-Version: 1.0
X-Received: by 10.107.47.97 with SMTP id j94mr28723647ioo.136.1441102811578;
 Tue, 01 Sep 2015 03:20:11 -0700 (PDT)
Received: by 10.79.78.66 with HTTP; Tue, 1 Sep 2015 03:20:11 -0700 (PDT)
In-Reply-To: <83a8t71qct.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
 <83a8t71qct.fsf@HIDDEN>
Date: Tue, 1 Sep 2015 10:20:11 +0000
Message-ID: <CAOqdjBd-AyHUyyGGh2y8qqSsZeFdSKJYJsNb_M7hk039_JnxWA@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/mixed; boundary=001a1144ac342b7664051eace58f
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a1144ac342b7664051eace58f
Content-Type: multipart/alternative; boundary=001a1144ac342b765f051eace58d

--001a1144ac342b765f051eace58d
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 31, 2015 at 2:31 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > Yes for this particular segfault.
>
> Can you show a patch that fixes the original segfault in your use
> case?


Attached. Note that either one of those changes should work. I'll test this
patch some more using my original code and see whether it blows up.

I'm afraid I lost track, what with all the different scenarios
> and potential solutions being thrown at this.  We should install the
> fix, assuming it's clean.
>

I think we should fix three things:
 - concat shouldn't rely on its argument remaining unchanged in length
 - the timer list copy should happen with block_input/unblock_input wrapped
around it
 - we shouldn't call do_pending_window_change from QUIT [already installed.
Thanks, martin!]

Any one of these is enough to prevent the original segfault. All but the
second also prevent the bizarre-elisp-induced segfault I came up with
later. And I'm perfectly happy for today with the number of hooks called
from QUIT reduced by one, rather than insisting on reducing them to zero
right away.

> No* for similar segfaults that I think pose equally severe problems: if
> any other function calls concat/copy-sequence on data that is modified by
> window-configuration-change-hook, it should* still be possible to produce
> the segfault.
>
> Emacs gives you enough rope to hang yourself; there's nothing new
> here.  We should strive to protect the Emacs internals so that they
> won't cause segfaults, but in user code any bets are off, and "don't
> do that" is a valid response to whoever does such things.
>

It's always good to know what the philosophy is behind the way the code
works, so thank you for that, really.

> So it wouldn't even be safe for window-configuration-change-hook to add a
> timer to the timer list, because the outer frame might be in the middle of
> creating a copy of the timer list for some Lisp code that hasn't blocked
> input. (As in my example below)
>
> Futzing with timers from within some hooks is indeed fundamentally
> dangerous.


Well, doing anything from window-configuration-change-hook is dangerous. My
idea was to schedule an immediate timer from it to get out of the danger
zone to do the actual work, but that backfired...


> But we should still try to minimize the probability of a
> crash, especially when it's Emacs itself who makes the offending copy,
> because people do dangerous things all the time, and expect them to
> work.  In this case, blocking input should do, I think.
>

I agree.

> I really don't think QUIT should run any Lisp hooks, to be honest.
>
> I don't think this limitation could fly.  It will disable a lot of
> useful use patterns, and the outcry will be loud and clear.
>

Okay.

> If I'm wrong and QUIT should be able to run Lisp hooks, concat needs to
> be fixed not to rely on its argument's size being unchanged after the
> make_sequence call.
>
> That can't do any harm, so let's do it, too.
>

Cool.


> > As far as I can tell, that should be reproducible. Also as far as I can
> tell, it's merely a matter of luck that an X resize doesn't happen at the
> point where I interrupted the program to artificially trigger the segfault.
> However, I admit that it is a separate issue, less likely to occur in
> practice, and I'll open another bug for it if that's the way you prefer
> things.
>
> But if input is blocked, as it would be in the case of copying
> timer-list inside timer_check, the X events will not be acted upon,
> and the problem will not happen, right?
>

Indeed, that relies on bizarre elisp code deliberately doing silly things...


> IOW, the above situation is a case of a user shooting herself in the
> foot by having that particular function in the hook and that
> particular code that copies timer-list (which is an internal variable
> unwise users should not touch).  Am I right?
>

I think you are. I'm not sure whether the timer code in timer.el does
anything to the timer list that might count as dangerous, but that's
possibly the only legitimate Lisp user of timer-list.

--001a1144ac342b765f051eace58d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Aug 31, 2015 at 2:31 PM, Eli Zaretskii <span dir=
=3D"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN=
</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><span>&gt; Yes for this particular segf=
ault.<br>
<br>
</span>Can you show a patch that fixes the original segfault in your use<br=
>
case?</blockquote><div><br></div><div>Attached. Note that either one of tho=
se changes should work. I&#39;ll test this patch some more using my origina=
l code and see whether it blows up.<br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"> I&#39;m afraid I lost track, what with all the different scenarios<br=
>
and potential solutions being thrown at this.=C2=A0 We should install the<b=
r>
fix, assuming it&#39;s clean.<br></blockquote><div><br></div><div>I think w=
e should fix three things:<br></div><div>=C2=A0- concat shouldn&#39;t rely =
on its argument remaining unchanged in length<br></div><div>=C2=A0- the tim=
er list copy should happen with block_input/unblock_input wrapped around it=
<br></div><div>=C2=A0- we shouldn&#39;t call do_pending_window_change from =
QUIT [already installed. Thanks, martin!]<br><br></div><div>Any one of thes=
e is enough to prevent the original segfault. All but the second also preve=
nt the bizarre-elisp-induced segfault I came up with later. And I&#39;m per=
fectly happy for today with the number of hooks called from QUIT reduced by=
 one, rather than insisting on reducing them to zero right away.<br><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<span>
&gt; No* for similar segfaults that I think pose equally severe problems: i=
f any other function calls concat/copy-sequence on data that is modified by=
 window-configuration-change-hook, it should* still be possible to produce =
the segfault.<br>
<br>
</span>Emacs gives you enough rope to hang yourself; there&#39;s nothing ne=
w<br>
here.=C2=A0 We should strive to protect the Emacs internals so that they<br=
>
won&#39;t cause segfaults, but in user code any bets are off, and &quot;don=
&#39;t<br>
do that&quot; is a valid response to whoever does such things.<br></blockqu=
ote><div><br></div><div>It&#39;s always good to know what the philosophy is=
 behind the way the code works, so thank you for that, really.<br><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<span>
&gt; So it wouldn&#39;t even be safe for window-configuration-change-hook t=
o add a timer to the timer list, because the outer frame might be in the mi=
ddle of creating a copy of the timer list for some Lisp code that hasn&#39;=
t blocked input. (As in my example below)<br>
<br>
</span>Futzing with timers from within some hooks is indeed fundamentally<b=
r>
dangerous.</blockquote><div><br></div><div>Well, doing anything from window=
-configuration-change-hook is dangerous. My idea was to schedule an immedia=
te timer from it to get out of the danger zone to do the actual work, but t=
hat backfired...<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> =
But we should still try to minimize the probability of a<br>
crash, especially when it&#39;s Emacs itself who makes the offending copy,<=
br>
because people do dangerous things all the time, and expect them to<br>
work.=C2=A0 In this case, blocking input should do, I think.<br></blockquot=
e><div><br></div><div>I agree.<br></div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<span>
&gt; I really don&#39;t think QUIT should run any Lisp hooks, to be honest.=
<br>
<br>
</span>I don&#39;t think this limitation could fly.=C2=A0 It will disable a=
 lot of<br>
useful use patterns, and the outcry will be loud and clear.<br></blockquote=
><br></div><div class=3D"gmail_quote">Okay.<br></div><div class=3D"gmail_qu=
ote"><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
<span>
&gt; If I&#39;m wrong and QUIT should be able to run Lisp hooks, concat nee=
ds to be fixed not to rely on its argument&#39;s size being unchanged after=
 the make_sequence call.<br>
<br>
</span>That can&#39;t do any harm, so let&#39;s do it, too.<span><br></span=
></blockquote><div><br></div><div>Cool.<br></div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><span>
&gt; As far as I can tell, that should be reproducible. Also as far as I ca=
n tell, it&#39;s merely a matter of luck that an X resize doesn&#39;t happe=
n at the point where I interrupted the program to artificially trigger the =
segfault. However, I admit that it is a separate issue, less likely to occu=
r in practice, and I&#39;ll open another bug for it if that&#39;s the way y=
ou prefer things.<br>
<br>
</span>But if input is blocked, as it would be in the case of copying<br>
timer-list inside timer_check, the X events will not be acted upon,<br>
and the problem will not happen, right?<br></blockquote><br></div><div clas=
s=3D"gmail_quote">Indeed, that relies on bizarre elisp code deliberately do=
ing silly things...<br></div><div class=3D"gmail_quote"><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">

IOW, the above situation is a case of a user shooting herself in the<br>
foot by having that particular function in the hook and that<br>
particular code that copies timer-list (which is an internal variable<br>
unwise users should not touch).=C2=A0 Am I right?<br>
</blockquote></div><br></div><div class=3D"gmail_extra">I think you are. I&=
#39;m not sure whether the timer code in timer.el does anything to the time=
r list that might count as dangerous, but that&#39;s possibly the only legi=
timate Lisp user of timer-list.<br></div></div>

--001a1144ac342b765f051eace58d--
--001a1144ac342b7664051eace58f
Content-Type: text/x-patch; charset=US-ASCII; 
	name="0001-Fix-potential-race-conditions-bug-23380.patch"
Content-Disposition: attachment; 
	filename="0001-Fix-potential-race-conditions-bug-23380.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_ie17enh80

RnJvbSA3ZTE4OGNhN2IwZTUxYmY3ZmZkYTQxM2NlYmM1M2RhOWViZmUwY2Q2IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXAgPHBpcGNldEBnbWFpbC5jb20+CkRhdGU6IFR1ZSwg
MSBTZXAgMjAxNSAxMDoxMjozMSArMDAwMApTdWJqZWN0OiBbUEFUQ0hdIEZpeCBwb3RlbnRpYWwg
cmFjZSBjb25kaXRpb25zIChidWcgIzIzMzgwKQoKICAgICAgICAqIGtleWJvYXJkLmMgKHRpbWVy
X2NoZWNrKTogQ2FsbCBgYmxvY2tfaW5wdXQnIGFyb3VuZCB0aGUgY3JlYXRpb24KCW9mIHRoZSB0
ZW1wb3JhcnkgdGltZXIgbGlzdCBjb3B5LgoKCSogZm5zLmMgKGNvbmNhdCk6IERvbid0IGFzc3Vt
ZSBhcmd1bWVudCBzaXplIHJlbWFpbnMgdW5jaGFuZ2VkCglhZnRlciBjYWxsIHRvIGBGbWFrZV9s
aXN0Jy4KLS0tCiBzcmMvZm5zLmMgICAgICB8IDMgKysrCiBzcmMva2V5Ym9hcmQuYyB8IDIgKysK
IDIgZmlsZXMgY2hhbmdlZCwgNSBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEvc3JjL2Zucy5j
IGIvc3JjL2Zucy5jCmluZGV4IDI2YTk4YWIuLjQzZmY1NTAgMTAwNjQ0Ci0tLSBhL3NyYy9mbnMu
YworKysgYi9zcmMvZm5zLmMKQEAgLTc0NCw2ICs3NDQsOSBAQCBjb25jYXQgKHB0cmRpZmZfdCBu
YXJncywgTGlzcF9PYmplY3QgKmFyZ3MsCiAJICAgIC8qIFN0b3JlIHRoaXMgZWxlbWVudCBpbnRv
IHRoZSByZXN1bHQuICAqLwogCSAgICBpZiAodG9pbmRleCA8IDApCiAJICAgICAgeworICAgICAg
ICAgICAgICAgIGlmIChFUSAodGFpbCwgUW5pbCkpCisgICAgICAgICAgICAgICAgICBicmVhazsK
KwogCQlYU0VUQ0FSICh0YWlsLCBlbHQpOwogCQlwcmV2ID0gdGFpbDsKIAkJdGFpbCA9IFhDRFIg
KHRhaWwpOwpkaWZmIC0tZ2l0IGEvc3JjL2tleWJvYXJkLmMgYi9zcmMva2V5Ym9hcmQuYwppbmRl
eCBkYWIzMmIxLi40YjdkNjc1IDEwMDY0NAotLS0gYS9zcmMva2V5Ym9hcmQuYworKysgYi9zcmMv
a2V5Ym9hcmQuYwpAQCAtNDU2MCw2ICs0NTYwLDcgQEAgdGltZXJfY2hlY2sgKHZvaWQpCiAKICAg
TGlzcF9PYmplY3QgdGVtID0gVmluaGliaXRfcXVpdDsKICAgVmluaGliaXRfcXVpdCA9IFF0Owor
ICBibG9ja19pbnB1dCAoKTsKIAogICAvKiBXZSB1c2UgY29waWVzIG9mIHRoZSB0aW1lcnMnIGxp
c3RzIHRvIGFsbG93IGEgdGltZXIgdG8gYWRkIGl0c2VsZgogICAgICBhZ2Fpbiwgd2l0aG91dCBs
b2NraW5nIHVwIEVtYWNzIGlmIHRoZSBuZXdseSBhZGRlZCB0aW1lciBpcwpAQCAtNDU3Myw2ICs0
NTc0LDcgQEAgdGltZXJfY2hlY2sgKHZvaWQpCiAgIGVsc2UKICAgICBpZGxlX3RpbWVycyA9IFFu
aWw7CiAKKyAgdW5ibG9ja19pbnB1dCAoKTsKICAgVmluaGliaXRfcXVpdCA9IHRlbTsKIAogICBk
bwotLSAKMi41LjAKCg==
--001a1144ac342b7664051eace58f--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 31 Aug 2015 14:32:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 31 10:32:26 2015
Received: from localhost ([127.0.0.1]:43752 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZWQ8I-0000uf-C8
	for submit <at> debbugs.gnu.org; Mon, 31 Aug 2015 10:32:26 -0400
Received: from mtaout22.012.net.il ([80.179.55.172]:40048)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1ZWQ8G-0000uW-0I
 for 21380 <at> debbugs.gnu.org; Mon, 31 Aug 2015 10:32:25 -0400
Received: from conversion-daemon.a-mtaout22.012.net.il by
 a-mtaout22.012.net.il (HyperSendmail v2007.08) id
 <0NTY00G00AY3RD00@HIDDEN> for 21380 <at> debbugs.gnu.org;
 Mon, 31 Aug 2015 17:31:37 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NTY00GABB0OO820@HIDDEN>;
 Mon, 31 Aug 2015 17:31:37 +0300 (IDT)
Date: Mon, 31 Aug 2015 17:31:46 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#21380: 25.0.50;
 GTK-induced segfault when scheduling timer from
 window-configuration-change-hook
In-reply-to: <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Pip Cet <pipcet@HIDDEN>
Message-id: <83a8t71qct.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Sun, 30 Aug 2015 20:56:33 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: 21380 <at> debbugs.gnu.org
> 
>     Then all we have to do is block QUIT during that copy, no?
> 
> Yes for this particular segfault.

Can you show a patch that fixes the original segfault in your use
case?  I'm afraid I lost track, what with all the different scenarios
and potential solutions being thrown at this.  We should install the
fix, assuming it's clean.

> No* for similar segfaults that I think pose equally severe problems: if any other function calls concat/copy-sequence on data that is modified by window-configuration-change-hook, it should* still be possible to produce the segfault.

Emacs gives you enough rope to hang yourself; there's nothing new
here.  We should strive to protect the Emacs internals so that they
won't cause segfaults, but in user code any bets are off, and "don't
do that" is a valid response to whoever does such things.

> So it wouldn't even be safe for window-configuration-change-hook to add a timer to the timer list, because the outer frame might be in the middle of creating a copy of the timer list for some Lisp code that hasn't blocked input. (As in my example below)

Futzing with timers from within some hooks is indeed fundamentally
dangerous.  But we should still try to minimize the probability of a
crash, especially when it's Emacs itself who makes the offending copy,
because people do dangerous things all the time, and expect them to
work.  In this case, blocking input should do, I think.

> I really don't think QUIT should run any Lisp hooks, to be honest.

I don't think this limitation could fly.  It will disable a lot of
useful use patterns, and the outcry will be loud and clear.

> If I'm wrong and QUIT should be able to run Lisp hooks, concat needs to be fixed not to rely on its argument's size being unchanged after the make_sequence call.

That can't do any harm, so let's do it, too.

> *-I have been able to verify this segfault by interrupting the program at just the right time and resizing its X window then:
>  - gdb --args emacs -Q
>  - evaluate the following code:
> 
> (run-with-timer 0 1 #'ignore) ;; so the timer list isn't empty
> (add-hook 'window-configuration-change-hook (lambda () (run-with-timer 0 nil #'ignore)))

> (while t
>   (copy-sequence timer-list)
>   (accept-process-output nil 0)
>   )
> 
>  - interrupt and set a breakpoint with "b Fmake_sequence if !input_blocked_p()".
>  - wait for breakpoint to be hit, verify that concat's args[0] is equal to Vtimer_list.
>  - resize the X window
>  - continue in gdb
>  - segfault
> 
> As far as I can tell, that should be reproducible. Also as far as I can tell, it's merely a matter of luck that an X resize doesn't happen at the point where I interrupted the program to artificially trigger the segfault. However, I admit that it is a separate issue, less likely to occur in practice, and I'll open another bug for it if that's the way you prefer things.

But if input is blocked, as it would be in the case of copying
timer-list inside timer_check, the X events will not be acted upon,
and the problem will not happen, right?

IOW, the above situation is a case of a user shooting herself in the
foot by having that particular function in the hook and that
particular code that copies timer-list (which is an internal variable
unwise users should not touch).  Am I right?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 31 Aug 2015 09:20:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 31 05:20:09 2015
Received: from localhost ([127.0.0.1]:43438 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZWLG4-0000Kb-MX
	for submit <at> debbugs.gnu.org; Mon, 31 Aug 2015 05:20:08 -0400
Received: from mout.gmx.net ([212.227.17.21]:58575)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rudalics@HIDDEN>) id 1ZWLG3-0000KT-59
 for 21380 <at> debbugs.gnu.org; Mon, 31 Aug 2015 05:20:07 -0400
Received: from [93.82.13.140] ([93.82.13.140]) by mail.gmx.com (mrgmx101) with
 ESMTPSA (Nemesis) id 0M6vSj-1YjJ2p0gbt-00woka;
 Mon, 31 Aug 2015 11:20:06 +0200
Message-ID: <55E41C44.90703@HIDDEN>
Date: Mon, 31 Aug 2015 11:20:04 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>	<83mvx8252m.fsf@HIDDEN>	<CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>	<CAOqdjBcg5-Y=kQDxVmCtV-UsnZgqr9z=anzL31MBVEES99p1LQ@HIDDEN>	<CAOqdjBd6EZ-zC0-AOa-XCawFSJkzfZzEWcp8O52qbi2Dxh=r5w@HIDDEN>	<55E34714.7080608@HIDDEN>
 <CAOqdjBcsSkfSPQq0q1JFRMjcogHkT91p2PtoPWchL_9QKnx8Qg@HIDDEN>
In-Reply-To: <CAOqdjBcsSkfSPQq0q1JFRMjcogHkT91p2PtoPWchL_9QKnx8Qg@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:PKClGxZi6pSUjZ9pxdfeUp3frlEJfDfZYwKPLFI5CnPIS6O4THM
 j8hI5i65rlOdvniY88/w5euWUCzpxFMnGzHBlf8ZKO/b8rXgy3A1wK8NWw2JbBm4nM/eZzd
 QkekrA6vM2oWtMl1BLttIxUT6RUmx1zon70MxK5hIxQGiHeZczdT+eX1muHmwCLTpVRO+lQ
 lpgsUcjrvOjsoQsN5TpYA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:Pj33QVrNFXw=:XRaXyxLAm1PAH1uvUeZWhB
 DQZpHXTEU+BJtW1l/+K4k1CRzVeD9zJcTVbGQF9asl6zHB+mIaQqDl1QnB8vGjeHoNcjTwwqE
 x7ssu8CIi1NbmFPkjDlEwhDeDNK7HIARAlgsl4yt7EeqDs6xPwiJshbVi76ZAhxkWJWF6gDVy
 zTllGSRgriFLfeB/CHKpW8PNKQj5Eh9LTLmB6r0fCPeCbQB/hqxyiP5uGReydSLKc23DZWL2v
 lkDZC7qwnwFaliWi5Ykbxw+5oeK43gA/iSkWqXshp+UTt1gykikYWNX7WHOfPfe0+UeZN7EkK
 r+V6ZNjdaRENQUOZGscz7CH76iKKqqc6phfEsjwyPR1wyg8LGd1F97957vz9z7V8mwJrNta0h
 oaMTJ1PzVPLoGPiPVl1aGumEfbjNcViCprVcqy6F/ydVUbVHzQflpcRtJpWIAkWlKIkEwxspy
 dwCv6IOUkaTOP0MiNLggfWG9XpAEWEI22kfHmXKk+nFdEg5FSGQJ4Gfy/v76f2QANsfVMupqg
 URkdd5OLCnjSRXEf83RRHlbMLEtMFR6lbII7MBj4EnVKQ/Gqm25DACJc4olOKFOgFLPcW6ZLm
 s3kG9GIkHdBJ6hg+bbLAdmO+MGqvmKDhYrnQA+qXATkR1OQ66CHl7JhyeNX2NZbtLARlereVZ
 2DWYLVLprqlpb8YBG4z99Klf3edXif/ZohK5TpKfzrq3kU92t1Gk4tao6+Si5QGixiFH2M1ie
 QpfxKbO08qbTsi34yexlqn1cDussxGTpvaHKxQ==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

 >> But I have no idea why this particular call
 >> of do_pending_window_change would run =E2=80=98window-configuration-c=
hange-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?

Indeed.  I removed the do_pending_window_change calls now.  I don't
recall why I thought that I needed them, maybe to get those border
clearing calls in synch with the resizing of the root window.  In any
case, judging from my ChangeLog entries, I must have had some sort of
premonition that this was a bad idea.

martin





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 21:13:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 30 17:13:05 2015
Received: from localhost ([127.0.0.1]:43137 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZW9uT-0006g1-58
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 17:13:05 -0400
Received: from mail-ig0-f178.google.com ([209.85.213.178]:32894)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZW9uQ-0006fq-Vx
 for 21380 <at> debbugs.gnu.org; Sun, 30 Aug 2015 17:13:03 -0400
Received: by igbuu8 with SMTP id uu8so36017759igb.0
 for <21380 <at> debbugs.gnu.org>; Sun, 30 Aug 2015 14:13:02 -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=z1/XSbnHIAMtP4jViqL6TlXvkYz5sfZFZVezLVilvns=;
 b=vNKqPdr/lMCeTA6n6vBG45rVqPDZ8dunkWF+XWgSlgriDVxRKo3fMEM67+LXUhoneX
 l/5PFbdcUzBwNA6X1pMUrn4DYal6SQMmOTa7ShqeSkpRo5Fs8L/MvjbBoeBo18mW5Q1f
 e8YrzwEnimseJ5yQ5ezAxD+bXa/0Gd819S42YwPT/v2jWrFBf6Ypngdzp/UwpIlVuY5s
 rAUIisbnwQgy488rNjBYC6bFCAxg1jur1G6jXSV/pYaQxlX19gnHU7SxKfKleg+O4URf
 yIqEbGf3LZxUX8VVUDNif/VN2bd19NW6kXdUKTz/xe4YIXfnfHFrjfnVmwu6Z9Pvmw0/
 3s5Q==
MIME-Version: 1.0
X-Received: by 10.50.17.9 with SMTP id k9mr12046834igd.93.1440969182427; Sun,
 30 Aug 2015 14:13:02 -0700 (PDT)
Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 14:13:02 -0700 (PDT)
In-Reply-To: <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
 <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
Date: Sun, 30 Aug 2015 21:13:02 +0000
Message-ID: <CAOqdjBdeMtZiBknw3SCDc=PzVHebcnGLGYWqmfn-jMsWuquFxg@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=089e01182a34403eec051e8dc8fc
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--089e01182a34403eec051e8dc8fc
Content-Type: text/plain; charset=UTF-8

On Sun, Aug 30, 2015 at 8:56 PM, Pip Cet <pipcet@HIDDEN> wrote:

> - interrupt and set a breakpoint with "b Fmake_sequence if
> !input_blocked_p()".
>

Fmake_list, sorry. I should also make it clear that I've tested this with
block_input/unblock_input where you suggested it (thus the
!input_blocked_p() in order not to catch that case). Please let me know if
you can't reproduce it or want me to send a gdb log or anything else.

Thanks again,
Pip

--089e01182a34403eec051e8dc8fc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sun, Aug 30, 2015 at 8:56 PM, Pip Cet <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:pipcet@HIDDEN" target=3D"_blank">pipcet@HIDDEN=
</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""></spa=
n> - interrupt and set a breakpoint with &quot;b Fmake_sequence if !input_b=
locked_p()&quot;. <br></div></blockquote><div><br></div><div>Fmake_list, so=
rry. I should also make it clear that I&#39;ve tested this with block_input=
/unblock_input where you suggested it (thus the !input_blocked_p() in order=
 not to catch that case). Please let me know if you can&#39;t reproduce it =
or want me to send a gdb log or anything else.<br><br></div><div>Thanks aga=
in,<br></div><div>Pip<br></div></div></div></div>

--089e01182a34403eec051e8dc8fc--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 20:56:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 30 16:56:37 2015
Received: from localhost ([127.0.0.1]:43121 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZW9eW-00068i-ID
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 16:56:37 -0400
Received: from mail-io0-f180.google.com ([209.85.223.180]:33166)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZW9eU-00068Z-J2
 for 21380 <at> debbugs.gnu.org; Sun, 30 Aug 2015 16:56:35 -0400
Received: by iods203 with SMTP id s203so139740119iod.0
 for <21380 <at> debbugs.gnu.org>; Sun, 30 Aug 2015 13:56:33 -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=qcOUrLzskIxIYKPHS0F3KgCziDG5uKGJ6OgyF7Dk/sQ=;
 b=CrpLInUmTtl1QyX/PknDVtdp4H7b2iLEwTfaaC+3HQd29n/imWCxpxcRSk/fyT06if
 41esC9v+EGLYbGKlkDRflvlzRsDjnW4wjplD4aKmz5K3nyQ4LgTsorLTX7+OyrdpPWt0
 z80l3P0/hYPkhk0363Od7Ws9KfLFC6TXqakjs8VYN/vTh6hPKMKDCteaSz3N+DD9ghwt
 rspHvFTSsrWEVKDxXT6f5lkezq6syxnYFzejPgI7PHXDjXneUVjoCuUQ0/dI8d7RadXM
 gQUm9oQeVF9TPoo+NpDtEpak8E2n0kDR/sISPTKE0x3tEbCMM2bO9g9BWbz0rVb5tgX2
 VRng==
MIME-Version: 1.0
X-Received: by 10.107.132.139 with SMTP id o11mr21144847ioi.3.1440968193677;
 Sun, 30 Aug 2015 13:56:33 -0700 (PDT)
Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 13:56:33 -0700 (PDT)
In-Reply-To: <83h9ng1ryx.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
 <83h9ng1ryx.fsf@HIDDEN>
Date: Sun, 30 Aug 2015 20:56:33 +0000
Message-ID: <CAOqdjBf_BMvcSW3szDd+KJpGR90EzrVWv4QhYVxWyMoVOm_x=g@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=001a113ed2f85121d9051e8d8d49
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a113ed2f85121d9051e8d8d49
Content-Type: text/plain; charset=UTF-8

On Sun, Aug 30, 2015 at 7:44 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > I'm not sure I understand. This issue is happening while the temporary
> copy is
> > being created, not afterwards, IIUC.
>
> Then all we have to do is block QUIT during that copy, no?


Yes for this particular segfault.

No* for similar segfaults that I think pose equally severe problems: if any
other function calls concat/copy-sequence on data that is modified by
window-configuration-change-hook, it should* still be possible to produce
the segfault. So it wouldn't even be safe for
window-configuration-change-hook to add a timer to the timer list, because
the outer frame might be in the middle of creating a copy of the timer list
for some Lisp code that hasn't blocked input. (As in my example below)

I really don't think QUIT should run any Lisp hooks, to be honest. From the
point of view of the Lisp user (and the not-totally-careful C user, as in
this case), that might make them happen at any time, and all kinds of race
conditions would occur instead. Maybe this is a matter for emacs-devel?

If I'm wrong and QUIT should be able to run Lisp hooks, concat needs to be
fixed not to rely on its argument's size being unchanged after the
make_sequence call.

*-I have been able to verify this segfault by interrupting the program at
just the right time and resizing its X window then:
 - gdb --args emacs -Q
 - evaluate the following code:

(run-with-timer 0 1 #'ignore) ;; so the timer list isn't empty
(add-hook 'window-configuration-change-hook (lambda () (run-with-timer 0
nil #'ignore)))

(while t
  (copy-sequence timer-list)
  (accept-process-output nil 0)
  )

 - interrupt and set a breakpoint with "b Fmake_sequence if
!input_blocked_p()".
 - wait for breakpoint to be hit, verify that concat's args[0] is equal to
Vtimer_list.
 - resize the X window
 - continue in gdb
 - segfault

As far as I can tell, that should be reproducible. Also as far as I can
tell, it's merely a matter of luck that an X resize doesn't happen at the
point where I interrupted the program to artificially trigger the segfault.
However, I admit that it is a separate issue, less likely to occur in
practice, and I'll open another bug for it if that's the way you prefer
things.

--001a113ed2f85121d9051e8d8d49
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sun, Aug 30, 2015 at 7:44 PM, Eli Zaretskii <span dir=
=3D"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN=
</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><span>&gt; I&#39;m n=
ot sure I understand. This issue is happening while the temporary copy is<b=
r>
&gt; being created, not afterwards, IIUC.<br>
<br>
</span>Then all we have to do is block QUIT during that copy, no?</blockquo=
te></div></div><div class=3D"gmail_extra"><br>Yes for this particular segfa=
ult.<br><br>No* for similar segfaults that I think pose equally severe prob=
lems: if any other function calls concat/copy-sequence on data that is modi=
fied by window-configuration-change-hook, it should* still be possible to p=
roduce the segfault. So it wouldn&#39;t even be safe for window-configurati=
on-change-hook to add a timer to the timer list, because the outer frame mi=
ght be in the middle of creating a copy of the timer list for some Lisp cod=
e that hasn&#39;t blocked input. (As in my example below)<br><br></div><div=
 class=3D"gmail_extra">I really don&#39;t think QUIT should run any Lisp ho=
oks, to be honest. From the point of view of the Lisp user (and the not-tot=
ally-careful C user, as in this case), that might make them happen at any t=
ime, and all kinds of race conditions would occur instead. Maybe this is a =
matter for emacs-devel?<br><br></div><div class=3D"gmail_extra">If I&#39;m =
wrong and QUIT should be able to run Lisp hooks, concat needs to be fixed n=
ot to rely on its argument&#39;s size being unchanged after the make_sequen=
ce call.<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_=
extra">*-I have been able to verify this segfault by interrupting the progr=
am at just the right time and resizing its X window then:<br>=C2=A0- gdb --=
args emacs -Q<br>=C2=A0- evaluate the following code:<br><br>(run-with-time=
r 0 1 #&#39;ignore) ;; so the timer list isn&#39;t empty<br>(add-hook &#39;=
window-configuration-change-hook (lambda () (run-with-timer 0 nil #&#39;ign=
ore)))<br><br>(while t<br>=C2=A0 (copy-sequence timer-list)<br>=C2=A0 (acce=
pt-process-output nil 0)<br>=C2=A0 )<br><br></div><div class=3D"gmail_extra=
">=C2=A0- interrupt and set a breakpoint with &quot;b Fmake_sequence if !in=
put_blocked_p()&quot;. <br>=C2=A0- wait for breakpoint to be hit, verify th=
at concat&#39;s args[0] is equal to Vtimer_list.<br></div><div class=3D"gma=
il_extra">=C2=A0- resize the X window<br></div><div class=3D"gmail_extra">=
=C2=A0- continue in gdb<br></div><div class=3D"gmail_extra">=C2=A0- segfaul=
t<br><br></div><div class=3D"gmail_extra">As far as I can tell, that should=
 be reproducible. Also as far as I can tell, it&#39;s merely a matter of lu=
ck that an X resize doesn&#39;t happen at the point where I interrupted the=
 program to artificially trigger the segfault. However, I admit that it is =
a separate issue, less likely to occur in practice, and I&#39;ll open anoth=
er bug for it if that&#39;s the way you prefer things.<br></div></div>

--001a113ed2f85121d9051e8d8d49--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 19:50:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 30 15:50:27 2015
Received: from localhost ([127.0.0.1]:43088 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZW8cV-0004Pl-4O
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 15:50:27 -0400
Received: from mtaout21.012.net.il ([80.179.55.169]:39568)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1ZW8cR-0004Pb-TG
 for 21380 <at> debbugs.gnu.org; Sun, 30 Aug 2015 15:50:25 -0400
Received: from conversion-daemon.a-mtaout21.012.net.il by
 a-mtaout21.012.net.il (HyperSendmail v2007.08) id
 <0NTW00900V1TL400@HIDDEN> for 21380 <at> debbugs.gnu.org;
 Sun, 30 Aug 2015 22:50:22 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NTW0091CV3XGLA0@HIDDEN>;
 Sun, 30 Aug 2015 22:50:22 +0300 (IDT)
Date: Sun, 30 Aug 2015 22:50:30 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#21380: 25.0.50;
 GTK-induced segfault when scheduling timer from
 window-configuration-change-hook
In-reply-to: <CAOqdjBfoiaJ1hy4w6gt=g2TtZDC5fSG1RfDZ+Y-Osya8vOtmNw@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Pip Cet <pipcet@HIDDEN>
Message-id: <83fv301rp5.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <CAOqdjBcg5-Y=kQDxVmCtV-UsnZgqr9z=anzL31MBVEES99p1LQ@HIDDEN>
 <CAOqdjBd6EZ-zC0-AOa-XCawFSJkzfZzEWcp8O52qbi2Dxh=r5w@HIDDEN>
 <55E34714.7080608@HIDDEN>
 <CAOqdjBfoiaJ1hy4w6gt=g2TtZDC5fSG1RfDZ+Y-Osya8vOtmNw@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 21380
Cc: rudalics@HIDDEN, 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Sun, 30 Aug 2015 18:20:42 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>, 21380 <at> debbugs.gnu.org
> 
>     Maybe. But the cause of the SEGFAULT must be elsewhere. I have no
>     idea how
>     
>     4. make_list interrupted by QUIT
>     
>     could happen "while the temporary copy is being created" when
>     timer_check has set Vinhibit_quit to t.
>     
> 
> inhibit_quit inhibits process_quit_flag(), but not process_pending_signals(),
> if I'm reading this correctly:
> 
> #define QUIT \
> do { \
> if (!NILP (Vquit_flag) && NILP (Vinhibit_quit)) \
> process_quit_flag (); \
> else if (pending_signals) \
> process_pending_signals (); \
> } while (false)
> 
> Maybe it should.

Does block_input/unblock_input around the copying solve the problem?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 19:44:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 30 15:44:35 2015
Received: from localhost ([127.0.0.1]:43084 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZW8Wp-0004HH-9r
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 15:44:35 -0400
Received: from mtaout20.012.net.il ([80.179.55.166]:45827)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1ZW8Wm-0004H7-75
 for 21380 <at> debbugs.gnu.org; Sun, 30 Aug 2015 15:44:33 -0400
Received: from conversion-daemon.a-mtaout20.012.net.il by
 a-mtaout20.012.net.il (HyperSendmail v2007.08) id
 <0NTW00900UG2QI00@HIDDEN> for 21380 <at> debbugs.gnu.org;
 Sun, 30 Aug 2015 22:44:30 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NTW009LHUU6KY60@HIDDEN>;
 Sun, 30 Aug 2015 22:44:30 +0300 (IDT)
Date: Sun, 30 Aug 2015 22:44:38 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#21380: 25.0.50;
 GTK-induced segfault when scheduling timer from
 window-configuration-change-hook
In-reply-to: <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Pip Cet <pipcet@HIDDEN>
Message-id: <83h9ng1ryx.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
 <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Sun, 30 Aug 2015 16:42:21 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: 21380 <at> debbugs.gnu.org
> 
>     > Does that make sense to you?
>     
>     It does, but there's one additional factor that was supposed to
>     prevent such problems: the first thing timer_check does is copy
>     Vtimer_list to a local variable; then it works on that copy. So
>     whatever happens in the meantime to Vtimer_list should not have
>     affected concat, because concat is called on a copy.
> 
> I'm not sure I understand. This issue is happening while the temporary copy is
> being created, not afterwards, IIUC.

Then all we have to do is block QUIT during that copy, no?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 18:59:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 30 14:59:58 2015
Received: from localhost ([127.0.0.1]:43038 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZW7pe-0003Bn-0x
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 14:59:58 -0400
Received: from mail-io0-f175.google.com ([209.85.223.175]:35264)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZW7pc-0003Bf-0Z
 for 21380 <at> debbugs.gnu.org; Sun, 30 Aug 2015 14:59:56 -0400
Received: by iog7 with SMTP id 7so14787450iog.2
 for <21380 <at> 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==
MIME-Version: 1.0
X-Received: by 10.107.47.97 with SMTP id j94mr21867283ioo.136.1440961195250;
 Sun, 30 Aug 2015 11:59:55 -0700 (PDT)
Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 11:59:55 -0700 (PDT)
In-Reply-To: <55E34714.7080608@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <CAOqdjBcg5-Y=kQDxVmCtV-UsnZgqr9z=anzL31MBVEES99p1LQ@HIDDEN>
 <CAOqdjBd6EZ-zC0-AOa-XCawFSJkzfZzEWcp8O52qbi2Dxh=r5w@HIDDEN>
 <55E34714.7080608@HIDDEN>
Date: Sun, 30 Aug 2015 18:59:55 +0000
Message-ID: <CAOqdjBcsSkfSPQq0q1JFRMjcogHkT91p2PtoPWchL_9QKnx8Qg@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Content-Type: multipart/alternative; boundary=001a1144ac342d99ec051e8becd1
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a1144ac342d99ec051e8becd1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Aug 30, 2015 at 6:10 PM, martin rudalics <span dir=3D"ltr">&lt;<a href=
=3D"mailto:rudalics@HIDDEN" target=3D"_blank">rudalics@HIDDEN</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
In my understanding the do_pending_window_change call is not needed and<br>
usually should be a noop. </blockquote><div><br></div><div>May I ask why? I=
 don&#39;t understand this code very well.<br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">But I have no idea why this particular call<br>
of do_pending_window_change would run =E2=80=98window-configuration-change-=
hook=E2=80=99<br>
and subsequently cause the havoc you describe.=C2=A0 The last<br>
change_frame_size should have just happened three lines before.<span><br></=
span></blockquote><div><br></div><div>But that had delay =3D=3D true, so ch=
ange_frame_size_1 never called adjust_frame_size, right?<br>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><span>

&gt; And my current understanding is this bug would not occur if that call =
were<br>
&gt; removed.</span></blockquote><div><br></div><div>...but possibly that w=
ouldn&#39;t work because of other things being called from GTK event handle=
rs.<br><br></div><div>Just thinking out loud for the rest of the Email:<br>=
</div>I&#39;m somewhat hesitant to mention this idea, but wouldn&#39;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=
&#39;ve just hit what appears to be another bug caused by asynchronous fram=
e destruction by GTK (I&#39;m creating and destroying many Emacs frames in =
my test code).<br></div></div></div>

--001a1144ac342d99ec051e8becd1--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 18:20:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 30 14:20:44 2015
Received: from localhost ([127.0.0.1]:43006 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZW7Dg-0002GZ-AF
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 14:20:44 -0400
Received: from mail-ig0-f178.google.com ([209.85.213.178]:34206)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZW7De-0002GR-MQ
 for 21380 <at> debbugs.gnu.org; Sun, 30 Aug 2015 14:20:43 -0400
Received: by igui7 with SMTP id i7so43924716igu.1
 for <21380 <at> debbugs.gnu.org>; Sun, 30 Aug 2015 11:20:42 -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=GzxB0cnIH2LBqxxOAo740sMT+ofgXi3UWkwQptQG3uc=;
 b=mIiThIeaN+4MQUuKp6Yi+3kyqqDyaACD0quOeTXLWGyuw479HiZMhEb5IiBd8RefM3
 i4Cf6cIYUluNNNgdB+IUT+iQd737+rHS9hgg3x2GlJkyRhmSw4hNfM6AtyHG6fZ3aXxk
 T25zHysouRUWx6yYaHDQfiKdU1sYP1uEkMhiOQHbFd4WbR2JKgl93EwKvU1b56nbTwAc
 Gp82n/CdjQplwkvby24jgwsZsclgEE+WvJbFij0q7rBNMk4aK776g1nQL3sW849FnCa3
 sEFJq2W4z60lTNBGYpl5NRUg4dvsfBRgvXsoifzzePorLogWXKFQNWNGGm2WNofGlwQj
 uUDQ==
MIME-Version: 1.0
X-Received: by 10.50.97.33 with SMTP id dx1mr10509694igb.1.1440958842121; Sun,
 30 Aug 2015 11:20:42 -0700 (PDT)
Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 11:20:42 -0700 (PDT)
In-Reply-To: <55E34714.7080608@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <CAOqdjBcg5-Y=kQDxVmCtV-UsnZgqr9z=anzL31MBVEES99p1LQ@HIDDEN>
 <CAOqdjBd6EZ-zC0-AOa-XCawFSJkzfZzEWcp8O52qbi2Dxh=r5w@HIDDEN>
 <55E34714.7080608@HIDDEN>
Date: Sun, 30 Aug 2015 18:20:42 +0000
Message-ID: <CAOqdjBfoiaJ1hy4w6gt=g2TtZDC5fSG1RfDZ+Y-Osya8vOtmNw@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Content-Type: multipart/alternative; boundary=047d7b10c889ebb72f051e8b5f58
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--047d7b10c889ebb72f051e8b5f58
Content-Type: text/plain; charset=UTF-8

On Sun, Aug 30, 2015 at 6:10 PM, martin rudalics <rudalics@HIDDEN> wrote:

> Remarkable.  I don't remember why I added them.  And obviously I have no
> idea why I wrote the ChangeLog entry in reverse.  Just as if I read diff
> output in the wrong direction.
>

I thought it might have been ANTINEWS month and I missed it :-)


> > And my current understanding is this bug would not occur if that call
> were
> > removed. The same issue applies to the change to x_set_window_size, but
> I'm
> > not certain about removing either call.
>
> Maybe.  But the cause of the SEGFAULT must be elsewhere.  I have no
> idea how
>
> 4. make_list interrupted by QUIT
>
> could happen "while the temporary copy is being created" when
> timer_check has set Vinhibit_quit to t.
>

inhibit_quit inhibits process_quit_flag(), but not
process_pending_signals(), if I'm reading this correctly:

#define QUIT                        \
  do {                            \
    if (!NILP (Vquit_flag) && NILP (Vinhibit_quit))    \
      process_quit_flag ();                \
    else if (pending_signals)                \
      process_pending_signals ();            \
  } while (false)

Maybe it should.

Regards,
Pip

--047d7b10c889ebb72f051e8b5f58
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sun, Aug 30, 2015 at 6:10 PM, martin rudalics <span dir=
=3D"ltr">&lt;<a href=3D"mailto:rudalics@HIDDEN" target=3D"_blank">rudalics@=
gmx.at</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Remarkable.=C2=
=A0 I don&#39;t remember why I added them.=C2=A0 And obviously I have no<br=
>
idea why I wrote the ChangeLog entry in reverse.=C2=A0 Just as if I read di=
ff<br>
output in the wrong direction.<br></blockquote><div><br></div><div>I though=
t it might have been ANTINEWS month and I missed it :-)<br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D""=
>
&gt; And my current understanding is this bug would not occur if that call =
were<br>
&gt; removed. The same issue applies to the change to x_set_window_size, bu=
t I&#39;m<br>
&gt; not certain about removing either call.<br>
<br></span>
Maybe.=C2=A0 But the cause of the SEGFAULT must be elsewhere.=C2=A0 I have =
no<br>
idea how<span class=3D""><br>
<br>
4. make_list interrupted by QUIT<br>
<br></span>
could happen &quot;while the temporary copy is being created&quot; when<br>
timer_check has set Vinhibit_quit to t.<span class=3D""><font color=3D"#888=
888"><br></font></span></blockquote><div><br></div><div>inhibit_quit inhibi=
ts process_quit_flag(), but not process_pending_signals(), if I&#39;m readi=
ng this correctly:<br><br>#define QUIT=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 \<br>=C2=A0 do {=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=
=C2=A0 \<br>=C2=A0=C2=A0=C2=A0 if (!NILP (Vquit_flag) &amp;&amp; NILP (Vinh=
ibit_quit))=C2=A0=C2=A0=C2=A0 \<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 process_q=
uit_flag ();=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=
=C2=A0=C2=A0 \<br>=C2=A0=C2=A0=C2=A0 else if (pending_signals)=C2=A0=C2=A0=
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 \<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 process_pending_signals ();=C2=A0=C2=A0=C2=A0 =C2=
=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 \<br>=C2=A0 } while (false)<br><br></div=
><div>Maybe it should.<br><br></div><div>Regards,<br></div><div>Pip<br></di=
v></div></div></div>

--047d7b10c889ebb72f051e8b5f58--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 18:10:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 30 14:10:46 2015
Received: from localhost ([127.0.0.1]:43002 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZW742-000224-0k
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 14:10:46 -0400
Received: from mout.gmx.net ([212.227.15.18]:50084)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rudalics@HIDDEN>) id 1ZW73z-00021v-B9
 for 21380 <at> debbugs.gnu.org; Sun, 30 Aug 2015 14:10:44 -0400
Received: from [188.22.232.77] ([188.22.232.77]) by mail.gmx.com (mrgmx002)
 with ESMTPSA (Nemesis) id 0ML72n-1ZVpwk3Iqv-000Oth; Sun, 30 Aug 2015 20:10:39
 +0200
Message-ID: <55E34714.7080608@HIDDEN>
Date: Sun, 30 Aug 2015 20:10:28 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: Pip Cet <pipcet@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>	<83mvx8252m.fsf@HIDDEN>	<CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>	<CAOqdjBcg5-Y=kQDxVmCtV-UsnZgqr9z=anzL31MBVEES99p1LQ@HIDDEN>
 <CAOqdjBd6EZ-zC0-AOa-XCawFSJkzfZzEWcp8O52qbi2Dxh=r5w@HIDDEN>
In-Reply-To: <CAOqdjBd6EZ-zC0-AOa-XCawFSJkzfZzEWcp8O52qbi2Dxh=r5w@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:OxUqQeaVpHW1MB4j75E5gXlJWNNTYlY9Gmz8UCWas13H95lqgiE
 eQZN0WRVwrqJqkvLOrkgSGNm89KVTVJ6TG2twMaPkomVEfKPJlmHYwKnGIBsa49L6KCKJtz
 W414vGm48WgLGT84/IOACwgjSwRoNTTevTGVNfTxR2ezzDRTcyQlJOWfdwsE9vArg3O1UBv
 hbhbxPv49j2PGE3+tTGCQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:48WAOO9ZmbQ=:q2qI2LvyrpeTFGXPYcppxD
 L/5XLXZ1MOXQFuA4avOK4HowYFLynUnyvbzjLKfU6vtZrsmY3/PzDcdUO0Asrze4K6HeqgKrm
 7Ru1srRaQ0JO8nxw76IxNfNJtFUSvNHF99y8/h88HemfDNHAMbFcQkIK8W6tTpUGN6d9xKfeG
 TxmmLaqVMxGoODyykPTuvxfGfbffo33PELD7LkH26156hWORE1DAbhvweIy8C6MYurgLYkzqi
 X/A6n9rtG4WXHMDKNwlkliqWDPM+WwQp7bRMr5VTPTyu+zh5L1hnMG4bJwL4A3PeO+onAjjlS
 JG7fExL3Pl+NdjcWQ8iJSjHbCVtW1/biAagoSsj6isFk5rfqysbPzdSu9bPOZ9NezNibhyiO2
 t88HBwxCqJVYSmaFL/LNQvyyJl3+LWuJoZ13gnOQUucIAZa4RvexF3X4PHA6k+0I/FHZTJJG/
 x9TtLLkdLMA+U8h+GorohwUjQOqabZxSwJ9puQv/JDD3wqCBDshve9z8mQ8f7ONWVvjwPoltq
 HGjBGKHE6R+cNoAjFZ3o52/Raf/sA0SZ9xbxW3ZcL3+j1x+e3pjvfRc2pQYl+wO/f9PAJcYTv
 2A31YC5ov7UOG/XAoXyCrBqgYqvWH6OxLhNGQemB9aYubjuC3BEaT8BpzspOJg++2pDLPwnFI
 1a6JvwQWqVqq3Guhc0/wBBL/lBKsmfL09+9YMtV6MFlRH3boqSwaEyhs5CjXomF/nSm0wfOQN
 a/yll/F0YGpc2qRu/Vib2zXpYHsdiHUvOXT8+w==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

 > I think the problem is the call to do_pending_window_change in
 > xg_frame_resized in gtkutil.c: the commit message (commit 3477e27021db=
)
 > says:
 >
 > Author:     Martin Rudalics <rudalics@HIDDEN>
 > AuthorDate: Sun Jul 27 15:21:30 2014 +0200
 > Commit:     Martin Rudalics <rudalics@HIDDEN>
 > CommitDate: Sun Jul 27 15:21:30 2014 +0200
 >
 >      Complete pixelwise frame/window resizing, add horizontal scrollba=
r
 > support.
 >      [...]
 >      * gtkutil.c (xg_frame_resized): Don't call
 >      do_pending_window_change.
 >
 > but the diff is:
 >
 > @@ -883,6 +884,8 @@ xg_frame_resized (struct frame *f, int pixelwidth,=
 int
 > pixelheight)
 >         change_frame_size (f, width, height, 0, 1, 0, 1);
 >         SET_FRAME_GARBAGED (f);
 >         cancel_mouse_face (f);
 > +
 > +      do_pending_window_change (0);
 >       }
 >   }

Remarkable.  I don't remember why I added them.  And obviously I have no
idea why I wrote the ChangeLog entry in reverse.  Just as if I read diff
output in the wrong direction.

In my understanding the do_pending_window_change call is not needed and
usually should be a noop.  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.

 > And my current understanding is this bug would not occur if that call =
were
 > removed. The same issue applies to the change to x_set_window_size, bu=
t I'm
 > not certain about removing either call.

Maybe.  But the cause of the SEGFAULT must be elsewhere.  I have no
idea how

4. make_list interrupted by QUIT

could happen "while the temporary copy is being created" when
timer_check has set Vinhibit_quit to t.

martin





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 16:42:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 30 12:42:25 2015
Received: from localhost ([127.0.0.1]:42894 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZW5gW-0008KF-Pt
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 12:42:25 -0400
Received: from mail-ig0-f177.google.com ([209.85.213.177]:34744)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZW5gU-0008K6-DO
 for 21380 <at> debbugs.gnu.org; Sun, 30 Aug 2015 12:42:22 -0400
Received: by igui7 with SMTP id i7so43207902igu.1
 for <21380 <at> debbugs.gnu.org>; Sun, 30 Aug 2015 09:42:21 -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=CIc/Hw7qwJ8g5kYLjzBwpR3UlR71GHVdOTbIIpdw+Do=;
 b=E3iwii73RPB3ig8GwFqlcbV0mQ402Z5PRjMoGzJSAuIwX07KRlUbR5RdcwcRWj2h3j
 pwD6DUyN0vFkbZDOWyZ5bnLdKCGKhZbaeTuFxe9VX+Xc+KKpRXsVivwIC7OrFrtYUA6+
 gSYqbGQjyrb9rfcNY/D65wtGJ8w8CUVpqwrrqLzjimvSTaTB+6O7qB/jAOQVko9weH6J
 lwDcWvy/UptC/s3As6YmMhZXcA6UuJ7KQ+vcilm5fWkTJlxlS2cseaI80TKN0+93aeF6
 +c5/GCkQikZiDXiBQX7u+r2ZrE8xhZsKzd+SSioNIG9lX2mcNDxd2ltA5epmJRBhTLv8
 1rCw==
MIME-Version: 1.0
X-Received: by 10.50.17.9 with SMTP id k9mr11426920igd.93.1440952941470; Sun,
 30 Aug 2015 09:42:21 -0700 (PDT)
Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 09:42:21 -0700 (PDT)
In-Reply-To: <83k2sc20k6.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <83k2sc20k6.fsf@HIDDEN>
Date: Sun, 30 Aug 2015 16:42:21 +0000
Message-ID: <CAOqdjBdh=cyA5d0NAv4fubvswUJ8QdNgCyp-iv=zdTZn+8w8uw@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=089e01182a3436eb35051e8a00df
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--089e01182a3436eb35051e8a00df
Content-Type: text/plain; charset=UTF-8

On Sun, Aug 30, 2015 at 4:39 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > Date: Sun, 30 Aug 2015 15:24:26 +0000
> > From: Pip Cet <pipcet@HIDDEN>
> > Cc: 21380 <at> debbugs.gnu.org
> >
> >     > Further investigation indicates that
> >     > window-configuration-change-hook was called in the middle of
> concat:
> >
> >     Did you understand how this fact is related to the segfault?
> >
> >
> > I _think_ I do.
> >
> > 1. concat called with args[0] == Vtimer_list
> > 2. concat stores result_len (=4)
> > 3. concat calls make_list (4)
> > 4. make_list interrupted by QUIT
> > 5. see stack trace
> > 6. window-configuration-change-hook modifies Vtimer_list, which now has
> length
> > 5
> > 7. control returns to concat
> > 8. concat tries to write 5 elements into a 4-element list, which causes
> the
> > segfault because `tail' is unexpectedly NULL.
> >
> > Does that make sense to you?
>
> It does, but there's one additional factor that was supposed to
> prevent such problems: the first thing timer_check does is copy
> Vtimer_list to a local variable; then it works on that copy.  So
> whatever happens in the meantime to Vtimer_list should not have
> affected concat, because concat is called on a copy.
>

I'm not sure I understand. This issue is happening while the temporary copy
is being created, not afterwards, IIUC.

--089e01182a3436eb35051e8a00df
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sun, Aug 30, 2015 at 4:39 PM, Eli Zaretskii <span dir=
=3D"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN=
</a>&gt;</span> wrote:<br><div><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">&gt; Date: Sun, 30 Aug 2015 15:24:=
26 +0000<br>
&gt; From: Pip Cet &lt;<a href=3D"mailto:pipcet@HIDDEN">pipcet@HIDDEN=
</a>&gt;<br>
&gt; Cc: <a href=3D"mailto:21380 <at> debbugs.gnu.org">21380 <at> debbugs.gnu.org</a>=
<br>
<span class=3D"">&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; Further investigation indicates that<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; window-configuration-change-hook was called in=
 the middle of concat:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0Did you understand how this fact is related to the =
segfault?<br>
&gt;<br>
&gt;<br>
&gt; I _think_ I do.<br>
&gt;<br>
&gt; 1. concat called with args[0] =3D=3D Vtimer_list<br>
&gt; 2. concat stores result_len (=3D4)<br>
&gt; 3. concat calls make_list (4)<br>
&gt; 4. make_list interrupted by QUIT<br>
&gt; 5. see stack trace<br>
&gt; 6. window-configuration-change-hook modifies Vtimer_list, which now ha=
s length<br>
&gt; 5<br>
&gt; 7. control returns to concat<br>
&gt; 8. concat tries to write 5 elements into a 4-element list, which cause=
s the<br>
&gt; segfault because `tail&#39; is unexpectedly NULL.<br>
&gt;<br>
&gt; Does that make sense to you?<br>
<br>
</span>It does, but there&#39;s one additional factor that was supposed to<=
br>
prevent such problems: the first thing timer_check does is copy<br>
Vtimer_list to a local variable; then it works on that copy.=C2=A0 So<br>
whatever happens in the meantime to Vtimer_list should not have<br>
affected concat, because concat is called on a copy.<br></blockquote><div><=
br></div><div>I&#39;m not sure I understand. This issue is happening while =
the temporary copy is being created, not afterwards, IIUC.<br></div></div><=
/div></div></div>

--089e01182a3436eb35051e8a00df--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 16:39:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 30 12:39:28 2015
Received: from localhost ([127.0.0.1]:42890 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZW5dg-0008Fo-2G
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 12:39:28 -0400
Received: from mtaout26.012.net.il ([80.179.55.182]:40118)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1ZW5dd-0008Fe-EH
 for 21380 <at> debbugs.gnu.org; Sun, 30 Aug 2015 12:39:26 -0400
Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il
 (HyperSendmail v2007.08) id <0NTW00800LZETN00@HIDDEN> for
 21380 <at> debbugs.gnu.org; Sun, 30 Aug 2015 19:41:04 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NTW000GSMCGF780@HIDDEN>; Sun, 30 Aug 2015 19:41:04 +0300 (IDT)
Date: Sun, 30 Aug 2015 19:39:05 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#21380: 25.0.50;
 GTK-induced segfault when scheduling timer from
 window-configuration-change-hook
In-reply-to: <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Pip Cet <pipcet@HIDDEN>
Message-id: <83k2sc20k6.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Sun, 30 Aug 2015 15:24:26 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: 21380 <at> debbugs.gnu.org
> 
>     > Further investigation indicates that
>     > window-configuration-change-hook was called in the middle of concat:
>     
>     Did you understand how this fact is related to the segfault?
>     
> 
> I _think_ I do.
> 
> 1. concat called with args[0] == Vtimer_list
> 2. concat stores result_len (=4)
> 3. concat calls make_list (4)
> 4. make_list interrupted by QUIT
> 5. see stack trace
> 6. window-configuration-change-hook modifies Vtimer_list, which now has length
> 5
> 7. control returns to concat
> 8. concat tries to write 5 elements into a 4-element list, which causes the
> segfault because `tail' is unexpectedly NULL.
> 
> Does that make sense to you?

It does, but there's one additional factor that was supposed to
prevent such problems: the first thing timer_check does is copy
Vtimer_list to a local variable; then it works on that copy.  So
whatever happens in the meantime to Vtimer_list should not have
affected concat, because concat is called on a copy.

Which part of this doesn't work, and why?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 16:25:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 30 12:25:00 2015
Received: from localhost ([127.0.0.1]:42885 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZW5Pf-0007up-5g
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 12:24:59 -0400
Received: from mail-io0-f181.google.com ([209.85.223.181]:36732)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZW5Pc-0007ud-7m
 for 21380 <at> debbugs.gnu.org; Sun, 30 Aug 2015 12:24:57 -0400
Received: by iod35 with SMTP id 35so6636349iod.3
 for <21380 <at> debbugs.gnu.org>; Sun, 30 Aug 2015 09:24: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=5Zg6HP1gweiQ3HDhGDtCA4dB0UlQD3SyeDixI+5i0Zk=;
 b=lGn4CFK1puDMlkeq23+W4Brkb5APNaIgABerDtKNRlh6o2uGAd8pKZNICId4G6CGZb
 hq/FxPbvR4zBUFtu3bKsmrWLDd2EeT6bK+CctVRz7qaHj21krslvZWQMJT9DPjXknYN7
 rYNV2vUAv7U2dM/DPGDB9j7NdKfnRyGRTvybKRcbXUOTYpJzuwnwlaEfN/zixm1MTBPb
 UpT2t5qrUUAqelpQMWXUlR7wQPZ8l9E7UCPZHuGKQzr+Xt4kn9SfDmQ/VgxQGsj3g6I5
 oenKE0VtRwKcGJEbtGAG5mlt8zJXeys+57m4MIwd0VvfCu2Ort8P/jrhn5ZagSWijf45
 y72g==
MIME-Version: 1.0
X-Received: by 10.107.47.97 with SMTP id j94mr21528385ioo.136.1440951895712;
 Sun, 30 Aug 2015 09:24:55 -0700 (PDT)
Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 09:24:55 -0700 (PDT)
In-Reply-To: <CAOqdjBcg5-Y=kQDxVmCtV-UsnZgqr9z=anzL31MBVEES99p1LQ@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
 <CAOqdjBcg5-Y=kQDxVmCtV-UsnZgqr9z=anzL31MBVEES99p1LQ@HIDDEN>
Date: Sun, 30 Aug 2015 16:24:55 +0000
Message-ID: <CAOqdjBd6EZ-zC0-AOa-XCawFSJkzfZzEWcp8O52qbi2Dxh=r5w@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=001a1144ac34e1e77f051e89c12a
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org, rudalics@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a1144ac34e1e77f051e89c12a
Content-Type: text/plain; charset=UTF-8

I think the problem is the call to do_pending_window_change in
xg_frame_resized in gtkutil.c: the commit message (commit 3477e27021db)
says:

Author:     Martin Rudalics <rudalics@HIDDEN>
AuthorDate: Sun Jul 27 15:21:30 2014 +0200
Commit:     Martin Rudalics <rudalics@HIDDEN>
CommitDate: Sun Jul 27 15:21:30 2014 +0200

    Complete pixelwise frame/window resizing, add horizontal scrollbar
support.
    [...]
    * gtkutil.c (xg_frame_resized): Don't call
    do_pending_window_change.

but the diff is:

@@ -883,6 +884,8 @@ xg_frame_resized (struct frame *f, int pixelwidth, int
pixelheight)
       change_frame_size (f, width, height, 0, 1, 0, 1);
       SET_FRAME_GARBAGED (f);
       cancel_mouse_face (f);
+
+      do_pending_window_change (0);
     }
 }

And my current understanding is this bug would not occur if that call were
removed. The same issue applies to the change to x_set_window_size, but I'm
not certain about removing either call.

On Sun, Aug 30, 2015 at 3:27 PM, Pip Cet <pipcet@HIDDEN> wrote:

> I forgot to make clear that I verified with gdb that args[0] ==
> Vtimer_list. And if there's anything else you would like me to debug,
> please let me know. It's very unfortunate I can't reproduce it with emacs
> -Q and I realize that makes it impossible for you to deal with this bug
> except through information I provide.
>
> Thanks for trying anyway,
> Pip
>
> On Sun, Aug 30, 2015 at 3:24 PM, Pip Cet <pipcet@HIDDEN> wrote:
>
>>
>>
>> On Sun, Aug 30, 2015 at 3:01 PM, Eli Zaretskii <eliz@HIDDEN> wrote:
>>
>>> > Date: Sun, 30 Aug 2015 12:51:26 +0000
>>> > From: Pip Cet <pipcet@HIDDEN>
>>> > Somehow, the argument to Fcopy_sequence was changed while concat was
>>> > underway.
>>>
>>> How do you see that?
>>>
>>
>> I originally concluded it was the only way to trigger the bug, but I just
>> managed to trigger it again and have it open in a GDB session:
>>
>> #1  0x00000000005efdb3 in concat (nargs=1, args=0x7fffffff76e8,
>> target_type=Lisp_Cons, last_special=false) at fns.c:747
>> 747                     XSETCAR (tail, elt);
>> (gdb) p result_len
>> $22 = 4
>> (gdb) p debug_print(Flength(args[0]))
>> 5
>> $23 = void
>> (gdb)
>>
>>
>>> > Further investigation indicates that
>>> > window-configuration-change-hook was called in the middle of concat:
>>>
>>> Did you understand how this fact is related to the segfault?
>>>
>>
>> I _think_ I do.
>>
>> 1. concat called with args[0] == Vtimer_list
>> 2. concat stores result_len (=4)
>> 3. concat calls make_list (4)
>> 4. make_list interrupted by QUIT
>> 5. see stack trace
>> 6. window-configuration-change-hook modifies Vtimer_list, which now has
>> length 5
>> 7. control returns to concat
>> 8. concat tries to write 5 elements into a 4-element list, which causes
>> the segfault because `tail' is unexpectedly NULL.
>>
>> Does that make sense to you?
>>
>> Thanks,
>> Pip
>>
>
>

--001a1144ac34e1e77f051e89c12a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>I think the problem is the call to do_pending_wi=
ndow_change in xg_frame_resized in gtkutil.c: the commit message (commit 34=
77e27021db) says:<br><br>Author:=C2=A0=C2=A0=C2=A0=C2=A0 Martin Rudalics &l=
t;<a href=3D"mailto:rudalics@HIDDEN" target=3D"_blank">rudalics@HIDDEN</a>&=
gt;<br>AuthorDate: Sun Jul 27 15:21:30 2014 +0200<br>Commit:=C2=A0=C2=A0=C2=
=A0=C2=A0 Martin Rudalics &lt;<a href=3D"mailto:rudalics@HIDDEN" target=3D"=
_blank">rudalics@HIDDEN</a>&gt;<br>CommitDate: Sun Jul 27 15:21:30 2014 +02=
00<br><br>=C2=A0=C2=A0=C2=A0 Complete pixelwise frame/window resizing, add =
horizontal scrollbar support.<br>=C2=A0=C2=A0=C2=A0 [...]<br>=C2=A0=C2=A0=
=C2=A0 * gtkutil.c (xg_frame_resized): Don&#39;t call<br>=C2=A0=C2=A0=C2=A0=
 do_pending_window_change.<br><br></div>but the diff is:<br><br>@@ -883,6 +=
884,8 @@ xg_frame_resized (struct frame *f, int pixelwidth, int pixelheight=
)<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 change_frame_size (f, width, heig=
ht, 0, 1, 0, 1);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SET_FRAME_GARBAGED=
 (f);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cancel_mouse_face (f);<br>+<b=
r>+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 do_pending_window_change (0);<br>=C2=A0=
=C2=A0=C2=A0=C2=A0 }<br>=C2=A0}<br><br></div><div></div><div>And my current=
 understanding is this bug would not occur if that call were removed. The s=
ame issue applies to the change to x_set_window_size, but I&#39;m not certa=
in about removing either call.<br></div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Sun, Aug 30, 2015 at 3:27 PM, Pip Cet <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:pipcet@HIDDEN" target=3D"_blank">pipc=
et@HIDDEN</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><div>I forgot to make clear that I verified with gdb that a=
rgs[0] =3D=3D Vtimer_list. And if there&#39;s anything else you would like =
me to debug, please let me know. It&#39;s very unfortunate I can&#39;t repr=
oduce it with emacs -Q and I realize that makes it impossible for you to de=
al with this bug except through information I provide.<br><br></div>Thanks =
for trying anyway,<br></div>Pip<br></div><div class=3D"HOEnZb"><div class=
=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, A=
ug 30, 2015 at 3:24 PM, Pip Cet <span dir=3D"ltr">&lt;<a href=3D"mailto:pip=
cet@HIDDEN" target=3D"_blank">pipcet@HIDDEN</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote"><span>On Sun, Aug 30, 2015 at 3:01 PM, E=
li Zaretskii <span dir=3D"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN" target=
=3D"_blank">eliz@HIDDEN</a>&gt;</span> wrote:<br></span><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><span>&gt; Date: Sun, 30 Aug 2015 12:51:26=
 +0000<br>
&gt; From: Pip Cet &lt;<a href=3D"mailto:pipcet@HIDDEN" target=3D"_blank=
">pipcet@HIDDEN</a>&gt;<br></span><span>
&gt; Somehow, the argument to Fcopy_sequence was changed while concat was<b=
r>
&gt; underway.<br>
<br>
How do you see that?<br></span></blockquote><div><br></div><div>I originall=
y concluded it was the only way to trigger the bug, but I just managed to t=
rigger it again and have it open in a GDB session:<br></div><div><br></div>=
<div>#1=C2=A0 0x00000000005efdb3 in concat (nargs=3D1, args=3D0x7fffffff76e=
8, target_type=3DLisp_Cons, last_special=3Dfalse) at fns.c:747<br>747=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XSETCAR (tail, elt);<br>(gdb) p res=
ult_len<br>$22 =3D 4<br>(gdb) p debug_print(Flength(args[0]))<br>5<br>$23 =
=3D void<br>(gdb) <br></div><span><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">

&gt; Further investigation indicates that<br>
&gt; window-configuration-change-hook was called in the middle of concat:<b=
r>
<br>
Did you understand how this fact is related to the segfault?<br></blockquot=
e><div><br></div></span><div>I _think_ I do.<br></div><div><br></div><div>1=
. concat called with args[0] =3D=3D Vtimer_list<br></div><div>2. concat sto=
res result_len (=3D4)<br></div><div>3. concat calls make_list (4)<br></div>=
<div>4. make_list interrupted by QUIT<br></div><div>5. see stack trace<br><=
/div><div>6. window-configuration-change-hook modifies Vtimer_list, which n=
ow has length 5<br></div><div>7. control returns to concat<br></div><div>8.=
 concat tries to write 5 elements into a 4-element list, which causes the s=
egfault because `tail&#39; is unexpectedly NULL.<br></div><div><br></div><d=
iv>Does that make sense to you?<br><br></div><div>Thanks,<br></div><div>Pip=
<br></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--001a1144ac34e1e77f051e89c12a--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 15:27:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 30 11:27:41 2015
Received: from localhost ([127.0.0.1]:42854 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZW4WD-0006cC-AD
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 11:27:41 -0400
Received: from mail-ig0-f180.google.com ([209.85.213.180]:34550)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZW4WB-0006c4-3h
 for 21380 <at> debbugs.gnu.org; Sun, 30 Aug 2015 11:27:39 -0400
Received: by igui7 with SMTP id i7so42650374igu.1
 for <21380 <at> debbugs.gnu.org>; Sun, 30 Aug 2015 08:27:38 -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=FgO7+UWSEoOq3UPtoAnHSbzwODGunTW3OV6/eMBqlFY=;
 b=hFDZjxBY6upjL29imHdT4NTqqROZy8KAxMU05FAmkp09hP7gw6QzqwEh+91F8ExqQO
 FjHULoKgR6o/PdsEiM2t3WpQQeRIBpd/DSUxOIFnURmgN8x9aWlGlLWmFC+6upGWInba
 jqxSBDZP1vbeDKoA11r2E72iugNNjuRKjnWU9fm8/OHKvxNjgqZbT+yWU4zkQ8oReKAI
 gUnltS6KbOPYycJqJq3dAJBCrKzyT+w/SUK4Bj8y0s6dabCxi63DPVDhSsa0ZLEsMjqm
 +NRDe7I96ke658D+bskuZ/uCUH32wIgw+dlALd/J86vp+XMVeCTajZc4N/JjmaDbYItV
 TnzQ==
MIME-Version: 1.0
X-Received: by 10.50.112.227 with SMTP id it3mr11233151igb.93.1440948458490;
 Sun, 30 Aug 2015 08:27:38 -0700 (PDT)
Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 08:27:38 -0700 (PDT)
In-Reply-To: <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
 <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
Date: Sun, 30 Aug 2015 15:27:38 +0000
Message-ID: <CAOqdjBcg5-Y=kQDxVmCtV-UsnZgqr9z=anzL31MBVEES99p1LQ@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=089e0102f83e0213e2051e88f582
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--089e0102f83e0213e2051e88f582
Content-Type: text/plain; charset=UTF-8

I forgot to make clear that I verified with gdb that args[0] ==
Vtimer_list. And if there's anything else you would like me to debug,
please let me know. It's very unfortunate I can't reproduce it with emacs
-Q and I realize that makes it impossible for you to deal with this bug
except through information I provide.

Thanks for trying anyway,
Pip

On Sun, Aug 30, 2015 at 3:24 PM, Pip Cet <pipcet@HIDDEN> wrote:

>
>
> On Sun, Aug 30, 2015 at 3:01 PM, Eli Zaretskii <eliz@HIDDEN> wrote:
>
>> > Date: Sun, 30 Aug 2015 12:51:26 +0000
>> > From: Pip Cet <pipcet@HIDDEN>
>> > Somehow, the argument to Fcopy_sequence was changed while concat was
>> > underway.
>>
>> How do you see that?
>>
>
> I originally concluded it was the only way to trigger the bug, but I just
> managed to trigger it again and have it open in a GDB session:
>
> #1  0x00000000005efdb3 in concat (nargs=1, args=0x7fffffff76e8,
> target_type=Lisp_Cons, last_special=false) at fns.c:747
> 747                     XSETCAR (tail, elt);
> (gdb) p result_len
> $22 = 4
> (gdb) p debug_print(Flength(args[0]))
> 5
> $23 = void
> (gdb)
>
>
>> > Further investigation indicates that
>> > window-configuration-change-hook was called in the middle of concat:
>>
>> Did you understand how this fact is related to the segfault?
>>
>
> I _think_ I do.
>
> 1. concat called with args[0] == Vtimer_list
> 2. concat stores result_len (=4)
> 3. concat calls make_list (4)
> 4. make_list interrupted by QUIT
> 5. see stack trace
> 6. window-configuration-change-hook modifies Vtimer_list, which now has
> length 5
> 7. control returns to concat
> 8. concat tries to write 5 elements into a 4-element list, which causes
> the segfault because `tail' is unexpectedly NULL.
>
> Does that make sense to you?
>
> Thanks,
> Pip
>

--089e0102f83e0213e2051e88f582
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>I forgot to make clear that I verified with gdb =
that args[0] =3D=3D Vtimer_list. And if there&#39;s anything else you would=
 like me to debug, please let me know. It&#39;s very unfortunate I can&#39;=
t reproduce it with emacs -Q and I realize that makes it impossible for you=
 to deal with this bug except through information I provide.<br><br></div>T=
hanks for trying anyway,<br></div>Pip<br></div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On Sun, Aug 30, 2015 at 3:24 PM, Pip Cet <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:pipcet@HIDDEN" target=3D"_blank">pip=
cet@HIDDEN</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><=
span class=3D"">On Sun, Aug 30, 2015 at 3:01 PM, Eli Zaretskii <span dir=3D=
"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a=
>&gt;</span> wrote:<br></span><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><span class=3D"">&gt; Date: Sun, 30 Aug 2015 12:51:26 +0000<br>
&gt; From: Pip Cet &lt;<a href=3D"mailto:pipcet@HIDDEN" target=3D"_blank=
">pipcet@HIDDEN</a>&gt;<br></span><span class=3D"">
&gt; Somehow, the argument to Fcopy_sequence was changed while concat was<b=
r>
&gt; underway.<br>
<br>
How do you see that?<br></span></blockquote><div><br></div><div>I originall=
y concluded it was the only way to trigger the bug, but I just managed to t=
rigger it again and have it open in a GDB session:<br></div><div><br></div>=
<div>#1=C2=A0 0x00000000005efdb3 in concat (nargs=3D1, args=3D0x7fffffff76e=
8, target_type=3DLisp_Cons, last_special=3Dfalse) at fns.c:747<br>747=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XSETCAR (tail, elt);<br>(gdb) p res=
ult_len<br>$22 =3D 4<br>(gdb) p debug_print(Flength(args[0]))<br>5<br>$23 =
=3D void<br>(gdb) <br></div><span class=3D""><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">

&gt; Further investigation indicates that<br>
&gt; window-configuration-change-hook was called in the middle of concat:<b=
r>
<br>
Did you understand how this fact is related to the segfault?<br></blockquot=
e><div><br></div></span><div>I _think_ I do.<br></div><div><br></div><div>1=
. concat called with args[0] =3D=3D Vtimer_list<br></div><div>2. concat sto=
res result_len (=3D4)<br></div><div>3. concat calls make_list (4)<br></div>=
<div>4. make_list interrupted by QUIT<br></div><div>5. see stack trace<br><=
/div><div>6. window-configuration-change-hook modifies Vtimer_list, which n=
ow has length 5<br></div><div>7. control returns to concat<br></div><div>8.=
 concat tries to write 5 elements into a 4-element list, which causes the s=
egfault because `tail&#39; is unexpectedly NULL.<br></div><div><br></div><d=
iv>Does that make sense to you?<br><br></div><div>Thanks,<br></div><div>Pip=
<br></div></div></div></div>
</blockquote></div><br></div>

--089e0102f83e0213e2051e88f582--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 15:24:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 30 11:24:29 2015
Received: from localhost ([127.0.0.1]:42850 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZW4T6-0006XZ-JN
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 11:24:28 -0400
Received: from mail-io0-f175.google.com ([209.85.223.175]:35260)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZW4T4-0006XR-Uv
 for 21380 <at> debbugs.gnu.org; Sun, 30 Aug 2015 11:24:27 -0400
Received: by iog7 with SMTP id 7so12205692iog.2
 for <21380 <at> debbugs.gnu.org>; Sun, 30 Aug 2015 08:24:26 -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=R3SFLx8lysYurQ900+tNl6dLusYOdzBYnPV3H76Djew=;
 b=tKWhBla+3QfoPmGlrW3qXnS7ZsPPhy0aBLVXvwr0N5UKc+zdjnndO1cLPcFvrUrGUO
 +2H8VSKts6LV5fDUdRImB93tNi/dSLsaBbpqWs+oW3tjKmXIpCa34Xh5z67ogAYYAUKX
 eIQSCpR8FQHaNiKCbgAMMfFnrc16gnScYEOPc5vPCj3iZh7Ye2+f23D4mPi2jpM9ebuW
 +P0ZVREiO5M19jSSRDHzvqhyrc5n2ZD0M/c4NfcXBR8KCxElfjcXKiLHvf+YITPiIyJa
 YicYo94FbBAT5J2GvzvKzaROnGASd/vlSqjG830dAvEl5raglJudILd+4eHXqUUCMLZN
 s5rQ==
MIME-Version: 1.0
X-Received: by 10.107.47.97 with SMTP id j94mr21375441ioo.136.1440948266140;
 Sun, 30 Aug 2015 08:24:26 -0700 (PDT)
Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 08:24:26 -0700 (PDT)
In-Reply-To: <83mvx8252m.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
 <83mvx8252m.fsf@HIDDEN>
Date: Sun, 30 Aug 2015 15:24:26 +0000
Message-ID: <CAOqdjBd5TLUNBcukB9Vt6UhYu1577Bry4CvSsBeB0OuXMbk3kg@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=001a1144ac348b0ffa051e88e9e2
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a1144ac348b0ffa051e88e9e2
Content-Type: text/plain; charset=UTF-8

On Sun, Aug 30, 2015 at 3:01 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > Date: Sun, 30 Aug 2015 12:51:26 +0000
> > From: Pip Cet <pipcet@HIDDEN>
> > Somehow, the argument to Fcopy_sequence was changed while concat was
> > underway.
>
> How do you see that?
>

I originally concluded it was the only way to trigger the bug, but I just
managed to trigger it again and have it open in a GDB session:

#1  0x00000000005efdb3 in concat (nargs=1, args=0x7fffffff76e8,
target_type=Lisp_Cons, last_special=false) at fns.c:747
747                     XSETCAR (tail, elt);
(gdb) p result_len
$22 = 4
(gdb) p debug_print(Flength(args[0]))
5
$23 = void
(gdb)


> > Further investigation indicates that
> > window-configuration-change-hook was called in the middle of concat:
>
> Did you understand how this fact is related to the segfault?
>

I _think_ I do.

1. concat called with args[0] == Vtimer_list
2. concat stores result_len (=4)
3. concat calls make_list (4)
4. make_list interrupted by QUIT
5. see stack trace
6. window-configuration-change-hook modifies Vtimer_list, which now has
length 5
7. control returns to concat
8. concat tries to write 5 elements into a 4-element list, which causes the
segfault because `tail' is unexpectedly NULL.

Does that make sense to you?

Thanks,
Pip

--001a1144ac348b0ffa051e88e9e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Aug 30, 2015 at 3:01 PM, Eli Zaretskii <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; Date: Sun=
, 30 Aug 2015 12:51:26 +0000<br>
&gt; From: Pip Cet &lt;<a href=3D"mailto:pipcet@HIDDEN">pipcet@HIDDEN=
</a>&gt;<br>
&gt; Somehow, the argument to Fcopy_sequence was changed while concat was<b=
r>
&gt; underway.<br>
<br>
How do you see that?<br></blockquote><div><br></div><div>I originally concl=
uded it was the only way to trigger the bug, but I just managed to trigger =
it again and have it open in a GDB session:<br></div><div><br></div><div>#1=
=C2=A0 0x00000000005efdb3 in concat (nargs=3D1, args=3D0x7fffffff76e8, targ=
et_type=3DLisp_Cons, last_special=3Dfalse) at fns.c:747<br>747=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XSETCAR (tail, elt);<br>(gdb) p result_le=
n<br>$22 =3D 4<br>(gdb) p debug_print(Flength(args[0]))<br>5<br>$23 =3D voi=
d<br>(gdb) <br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">

&gt; Further investigation indicates that<br>
&gt; window-configuration-change-hook was called in the middle of concat:<b=
r>
<br>
Did you understand how this fact is related to the segfault?<br></blockquot=
e><div><br></div><div>I _think_ I do.<br></div><div><br></div><div>1. conca=
t called with args[0] =3D=3D Vtimer_list<br></div><div>2. concat stores res=
ult_len (=3D4)<br></div><div>3. concat calls make_list (4)<br></div><div>4.=
 make_list interrupted by QUIT<br></div><div>5. see stack trace<br></div><d=
iv>6. window-configuration-change-hook modifies Vtimer_list, which now has =
length 5<br></div><div>7. control returns to concat<br></div><div>8. concat=
 tries to write 5 elements into a 4-element list, which causes the segfault=
 because `tail&#39; is unexpectedly NULL.<br></div><div><br></div><div>Does=
 that make sense to you?<br><br></div><div>Thanks,<br></div><div>Pip<br></d=
iv></div></div></div>

--001a1144ac348b0ffa051e88e9e2--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at 21380 <at> debbugs.gnu.org:


Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 15:01:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 30 11:01:50 2015
Received: from localhost ([127.0.0.1]:42838 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZW47B-00061H-HR
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 11:01:49 -0400
Received: from mtaout28.012.net.il ([80.179.55.184]:58363)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1ZW477-000617-1i
 for 21380 <at> debbugs.gnu.org; Sun, 30 Aug 2015 11:01:47 -0400
Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il
 (HyperSendmail v2007.08) id <0NTW00B00HJO4W00@HIDDEN> for
 21380 <at> debbugs.gnu.org; Sun, 30 Aug 2015 18:01:20 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NTW0054THQ84Z70@HIDDEN>; Sun, 30 Aug 2015 18:01:20 +0300 (IDT)
Date: Sun, 30 Aug 2015 18:01:37 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from	window-configuration-change-hook
In-reply-to: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Pip Cet <pipcet@HIDDEN>
Message-id: <83mvx8252m.fsf@HIDDEN>
References: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 21380
Cc: 21380 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Sun, 30 Aug 2015 12:51:26 +0000
> From: Pip Cet <pipcet@HIDDEN>
> 
> It appears it's unsafe to schedule an immediate timer in
> window-configuration-change-hook:
> 
> (add-hook 'window-configuration-change-hook (lambda () (run-with-timer
> 0 nil 'exwm-layout--refresh)))
> 
> I saw the following segfault:
> #0 0x0000000000547ec0 in XSETCAR (c=0, n=51872517) at lisp.h:1188
> #1 0x00000000005efdb3 in concat (nargs=1, args=0x7fffffffd868,
> target_type=Lisp_Cons, last_special=false) at fns.c:747
> #2 0x00000000005ef0f3 in Fcopy_sequence (arg=53371635) at fns.c:510
> #3 0x0000000000557252 in timer_check () at keyboard.c:4569
> #4 0x0000000000639f1b in wait_reading_process_output (time_limit=30, nsecs=0,
> read_kbd=-1, do_display=true, wait_for_cell=0, wait_proc=0x0, just_wait_proc=0)
> at process.c:4611
> #5 0x00000000004233b2 in sit_for (timeout=122, reading=true, display_option=1)
> at dispnew.c:5756
> #6 0x0000000000553942 in read_char (commandflag=1, map=53372867, prev_event=0,
> used_mouse_menu=0x7fffffffe06f, end_time=0x0) at keyboard.c:2775
> #7 0x00000000005602ef in read_key_sequence (keybuf=0x7fffffffe220, bufsize=30,
> prompt=0, dont_downcase_last=false, can_return_switch_frame=true,
> fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9139
> #8 0x00000000005507b1 in command_loop_1 () at keyboard.c:1406
> #9 0x00000000005e77e4 in internal_condition_case (bfun=0x550386
> <command_loop_1>, handlers=18912, hfun=0x54fb70 <cmd_error>) at eval.c:1293
> #10 0x000000000055008d in command_loop_2 (ignore=0) at keyboard.c:1138
> #11 0x00000000005e6fa6 in internal_catch (tag=45264, func=0x550064
> <command_loop_2>, arg=0) at eval.c:1057
> #12 0x000000000055002f in command_loop () at keyboard.c:1117
> #13 0x000000000054f738 in recursive_edit_1 () at keyboard.c:723
> #14 0x000000000054f8cc in Frecursive_edit () at keyboard.c:794
> #15 0x000000000054d706 in main (argc=5, argv=0x7fffffffe6a8) at emacs.c:1643
> 
> Somehow, the argument to Fcopy_sequence was changed while concat was
> underway.

How do you see that?

> Further investigation indicates that
> window-configuration-change-hook was called in the middle of concat:

Did you understand how this fact is related to the segfault?

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 30 Aug 2015 12:51:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 30 08:51:41 2015
Received: from localhost ([127.0.0.1]:42533 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZW25D-0001pR-WF
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 08:51:41 -0400
Received: from eggs.gnu.org ([208.118.235.92]:43544)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <pipcet@HIDDEN>) id 1ZW25A-0001pG-Bu
 for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 08:51:38 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <pipcet@HIDDEN>) id 1ZW257-0003dv-A6
 for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 08:51:35 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
 HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:48838)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <pipcet@HIDDEN>) id 1ZW257-0003dr-6h
 for submit <at> debbugs.gnu.org; Sun, 30 Aug 2015 08:51:33 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:53518)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <pipcet@HIDDEN>) id 1ZW254-0001Yn-QA
 for bug-gnu-emacs@HIDDEN; Sun, 30 Aug 2015 08:51:33 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <pipcet@HIDDEN>) id 1ZW251-0003dA-UF
 for bug-gnu-emacs@HIDDEN; Sun, 30 Aug 2015 08:51:30 -0400
Received: from mail-io0-x22d.google.com ([2607:f8b0:4001:c06::22d]:34416)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <pipcet@HIDDEN>) id 1ZW251-0003cy-Mg
 for bug-gnu-emacs@HIDDEN; Sun, 30 Aug 2015 08:51:27 -0400
Received: by iofe124 with SMTP id e124so68364776iof.1
 for <bug-gnu-emacs@HIDDEN>; Sun, 30 Aug 2015 05:51:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:date:message-id:subject:from:to:content-type;
 bh=gv2S2cRDhZOePH4g5XFP4KbY6WPQWL/Oa/Ot3oMsvX4=;
 b=vYb++J3ux+gSq4me9zO/ReNn62k/f3BTp3f90i5svKf7eXDYlzyAVWM/X0+ZrrJSqF
 QKRa+CHX2u0J6PtJeYXub0dInkGc48a7nnXrWC7/P6OVmCS0VlAOOb+8HKyx3Qq+yqsL
 1USv0vW370wUrd5LBm+vIT6nSYbongdTFvjbnQNuOhtG9Pfr0nWqOpVLfhH2Xeg8mJ/v
 0doybC/nn+qe5kIqimn/0tjdAz+ZlRcVPuTCiTEHRmV8hBnAFk4GamdldTy8fPOXnL1g
 U3RUeroa0dCZxslYcTQ08/Go/3nzQ7TmjC+TagRImXKhATQ1ibqjT17FDbYCsEj9bDuW
 IRyQ==
MIME-Version: 1.0
X-Received: by 10.107.47.97 with SMTP id j94mr20915836ioo.136.1440939086746;
 Sun, 30 Aug 2015 05:51:26 -0700 (PDT)
Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 05:51:26 -0700 (PDT)
Date: Sun, 30 Aug 2015 12:51:26 +0000
Message-ID: <CAOqdjBcHpNB4vqfybnXszDKSmzuqnEvHTxbEhGy-R0STy-ma4Q@HIDDEN>
Subject: 25.0.50; GTK-induced segfault when scheduling timer from
 window-configuration-change-hook
From: Pip Cet <pipcet@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Content-Type: multipart/alternative; boundary=001a1144ac34689f02051e86c67d
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.0 (----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.0 (----)

--001a1144ac34689f02051e86c67d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

It appears it's unsafe to schedule an immediate timer in
window-configuration-change-hook:

  (add-hook 'window-configuration-change-hook (lambda () (run-with-timer
                                                          0 nil
'exwm-layout--refresh)))

I saw the following segfault:
#0  0x0000000000547ec0 in XSETCAR (c=3D0, n=3D51872517) at lisp.h:1188
#1  0x00000000005efdb3 in concat (nargs=3D1, args=3D0x7fffffffd868,
target_type=3DLisp_Cons, last_special=3Dfalse) at fns.c:747
#2  0x00000000005ef0f3 in Fcopy_sequence (arg=3D53371635) at fns.c:510
#3  0x0000000000557252 in timer_check () at keyboard.c:4569
#4  0x0000000000639f1b in wait_reading_process_output (time_limit=3D30,
nsecs=3D0, read_kbd=3D-1, do_display=3Dtrue, wait_for_cell=3D0, wait_proc=
=3D0x0,
just_wait_proc=3D0) at process.c:4611
#5  0x00000000004233b2 in sit_for (timeout=3D122, reading=3Dtrue,
display_option=3D1) at dispnew.c:5756
#6  0x0000000000553942 in read_char (commandflag=3D1, map=3D53372867,
prev_event=3D0, used_mouse_menu=3D0x7fffffffe06f, end_time=3D0x0) at
keyboard.c:2775
#7  0x00000000005602ef in read_key_sequence (keybuf=3D0x7fffffffe220,
bufsize=3D30, prompt=3D0, dont_downcase_last=3Dfalse,
can_return_switch_frame=3Dtrue, fix_current_buffer=3Dtrue,
prevent_redisplay=3Dfalse) at keyboard.c:9139
#8  0x00000000005507b1 in command_loop_1 () at keyboard.c:1406
#9  0x00000000005e77e4 in internal_condition_case (bfun=3D0x550386
<command_loop_1>, handlers=3D18912, hfun=3D0x54fb70 <cmd_error>) at eval.c:=
1293
#10 0x000000000055008d in command_loop_2 (ignore=3D0) at keyboard.c:1138
#11 0x00000000005e6fa6 in internal_catch (tag=3D45264, func=3D0x550064
<command_loop_2>, arg=3D0) at eval.c:1057
#12 0x000000000055002f in command_loop () at keyboard.c:1117
#13 0x000000000054f738 in recursive_edit_1 () at keyboard.c:723
#14 0x000000000054f8cc in Frecursive_edit () at keyboard.c:794
#15 0x000000000054d706 in main (argc=3D5, argv=3D0x7fffffffe6a8) at emacs.c=
:1643

Somehow, the argument to Fcopy_sequence was changed while concat was
underway. Further investigation indicates that
window-configuration-change-hook was called in the middle of concat:

Breakpoint 8, run_window_configuration_change_hook (f=3D0x1718660) at
window.c:3141
3141      ptrdiff_t count =3D SPECPDL_INDEX ();
#0  run_window_configuration_change_hook (f=3D0x1718660) at window.c:3141
#1  0x0000000000425882 in adjust_frame_size (f=3D0x1718660, new_width=3D824=
,
new_height=3D516, inhibit=3D5, pretend=3Dfalse, parameter=3D13152) at frame=
.c:599
#2  0x0000000000422c01 in change_frame_size_1 (f=3D0x1718660, new_width=3D8=
24,
new_height=3D516, pretend=3Dfalse, delay=3Dfalse, safe=3Dfalse, pixelwise=
=3Dtrue) at
dispnew.c:5507
#3  0x0000000000422c57 in change_frame_size (f=3D0x1718660, new_width=3D824=
,
new_height=3D516, pretend=3Dfalse, delay=3Dfalse, safe=3Dfalse, pixelwise=
=3Dtrue) at
dispnew.c:5539
#4  0x0000000000422a2f in do_pending_window_change (safe=3Dfalse) at
dispnew.c:5465
#5  0x0000000000536c22 in xg_frame_resized (f=3D0x1718660, pixelwidth=3D842=
,
pixelheight=3D518) at gtkutil.c:924
#6  0x0000000000518a9f in handle_one_xevent (dpyinfo=3D0x15b07d0,
event=3D0x7fffffff7210, finish=3D0xbfaacc, hold_quit=3D0x7fffffff74a0) at
xterm.c:8294
#7  0x0000000000516a69 in event_handler_gdk (gxev=3D0x7fffffff7210,
ev=3D0x568b410, data=3D0x0) at xterm.c:7294
#8  0x00007ffff6769661 in gdk_event_apply_filters
(xevent=3Dxevent@entry=3D0x7fffffff7210,
event=3Devent@entry=3D0x568b410, window=3Dwindow@entry=3D0x0) at
/tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkeventsource.c:81
#9  0x00007ffff6769929 in gdk_event_source_translate_event
(xevent=3D0x7fffffff7210, event_source=3D0x14e4090) at
/tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkeventsource.c:195
#10 _gdk_x11_display_queue_events (display=3D0x1506050) at
/tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkeventsource.c:338
#11 0x00007ffff673cae9 in gdk_display_get_event
(display=3Ddisplay@entry=3D0x1506050)
at /tmp/buildd/gtk+3.0-3.16.6/./gdk/gdkdisplay.c:340
#12 0x00007ffff67696e2 in gdk_event_source_dispatch (source=3D<optimized
out>, callback=3D<optimized out>, user_data=3D<optimized out>) at
/tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkeventsource.c:360
#13 0x00007ffff50bac3d in g_main_dispatch (context=3D0x14f1f80) at
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3122
#14 g_main_context_dispatch (context=3Dcontext@entry=3D0x14f1f80) at
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737
#15 0x00007ffff50baf20 in g_main_context_iterate
(context=3Dcontext@entry=3D0x14f1f80,
block=3Dblock@entry=3D1, dispatch=3Ddispatch@entry=3D1, self=3D<optimized o=
ut>) at
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3808
#16 0x00007ffff50bafcc in g_main_context_iteration (context=3D0x14f1f80,
context@entry=3D0x0, may_block=3Dmay_block@entry=3D1) at
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3869
#17 0x00007ffff6be1ff5 in gtk_main_iteration () at
/tmp/buildd/gtk+3.0-3.16.6/./gtk/gtkmain.c:1320
#18 0x0000000000519220 in XTread_socket (terminal=3D0x11ecdd0,
hold_quit=3D0x7fffffff74a0) at xterm.c:8644
#19 0x000000000055bbe2 in gobble_input () at keyboard.c:6893
#20 0x000000000055bfcc in handle_async_input () at keyboard.c:7145
#21 0x000000000055bfeb in process_pending_signals () at keyboard.c:7159
#22 0x00000000005c3d3a in Fmake_list (length=3D0, init=3D0) at alloc.c:2676
#23 0x00000000005ef6f8 in concat (nargs=3D1, args=3D0x7fffffff76e8,
target_type=3DLisp_Cons, last_special=3Dfalse) at fns.c:642
#24 0x00000000005ef0f3 in Fcopy_sequence (arg=3D49369891) at fns.c:510
#25 0x0000000000557252 in timer_check () at keyboard.c:4569
#26 0x0000000000555106 in readable_events (flags=3D1) at keyboard.c:3422
#27 0x000000000055ba2b in get_input_pending (flags=3D1) at keyboard.c:6808
#28 0x0000000000556a49 in swallow_events (do_display=3Dfalse) at
keyboard.c:4320
#29 0x000000000063af9c in wait_reading_process_output (time_limit=3D1,
nsecs=3D0, read_kbd=3D0, do_display=3Dfalse, wait_for_cell=3D0,
wait_proc=3D0x2fd6078, just_wait_proc=3D0) at process.c:4992
#30 0x0000000000638f6c in Faccept_process_output (process=3D50159736,
seconds=3D6, millisec=3D0, just_this_one=3D0) at process.c:4241

I'm not sure whether the bug is in my code (and, if so, how to fix
it=E2=80=94if scheduling an immediate timer isn't safe, what could possibly
be?), in Fmake_list, in QUIT, or in the X or GTK code, but at least
one of them is buggy.

M-x report-emacs-bug information:

I have been unable, so far, to reproduce this bug reliably from `emacs
-Q'.

In GNU Emacs 25.0.50.52 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6)
 of 2015-08-30
Repository revision: c6af816affb36d512f806725518e6e5f2353b197
Windowing system distributor `The X.Org Foundation', version 11.0.11702000
System Description:    Debian GNU/Linux unstable (sid)

Configured using:
 `configure 'CFLAGS=3D-O0 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GCONF GSETTINGS NOTIFY LIBSELINUX
GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
  diff-auto-refine-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns help-mode cl-loaddefs pcase cl-lib mail-prsvr
mail-utils vc-git diff-mode easymenu easy-mmode time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 84908 4447)
 (symbols 48 19432 0)
 (miscs 40 43 147)
 (strings 32 14795 4332)
 (string-bytes 1 417071)
 (vectors 16 11731)
 (vector-slots 8 419664 4375)
 (floats 8 138 302)
 (intervals 56 225 13)
 (buffers 976 12)
 (heap 1024 19426 1811))

--001a1144ac34689f02051e86c67d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It appears it&#39;s unsafe to schedule an immediate timer =
in<br>window-configuration-change-hook:<br><br>=C2=A0 (add-hook &#39;window=
-configuration-change-hook (lambda () (run-with-timer<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 0 nil &#39;exwm-layout--refresh)))<br><br>I saw th=
e following segfault:<br>#0=C2=A0 0x0000000000547ec0 in XSETCAR (c=3D0, n=
=3D51872517) at lisp.h:1188<br>#1=C2=A0 0x00000000005efdb3 in concat (nargs=
=3D1, args=3D0x7fffffffd868, target_type=3DLisp_Cons, last_special=3Dfalse)=
 at fns.c:747<br>#2=C2=A0 0x00000000005ef0f3 in Fcopy_sequence (arg=3D53371=
635) at fns.c:510<br>#3=C2=A0 0x0000000000557252 in timer_check () at keybo=
ard.c:4569<br>#4=C2=A0 0x0000000000639f1b in wait_reading_process_output (t=
ime_limit=3D30, nsecs=3D0, read_kbd=3D-1, do_display=3Dtrue, wait_for_cell=
=3D0, wait_proc=3D0x0, just_wait_proc=3D0) at process.c:4611<br>#5=C2=A0 0x=
00000000004233b2 in sit_for (timeout=3D122, reading=3Dtrue, display_option=
=3D1) at dispnew.c:5756<br>#6=C2=A0 0x0000000000553942 in read_char (comman=
dflag=3D1, map=3D53372867, prev_event=3D0, used_mouse_menu=3D0x7fffffffe06f=
, end_time=3D0x0) at keyboard.c:2775<br>#7=C2=A0 0x00000000005602ef in read=
_key_sequence (keybuf=3D0x7fffffffe220, bufsize=3D30, prompt=3D0, dont_down=
case_last=3Dfalse, can_return_switch_frame=3Dtrue, fix_current_buffer=3Dtru=
e, prevent_redisplay=3Dfalse) at keyboard.c:9139<br>#8=C2=A0 0x000000000055=
07b1 in command_loop_1 () at keyboard.c:1406<br>#9=C2=A0 0x00000000005e77e4=
 in internal_condition_case (bfun=3D0x550386 &lt;command_loop_1&gt;, handle=
rs=3D18912, hfun=3D0x54fb70 &lt;cmd_error&gt;) at eval.c:1293<br>#10 0x0000=
00000055008d in command_loop_2 (ignore=3D0) at keyboard.c:1138<br>#11 0x000=
00000005e6fa6 in internal_catch (tag=3D45264, func=3D0x550064 &lt;command_l=
oop_2&gt;, arg=3D0) at eval.c:1057<br>#12 0x000000000055002f in command_loo=
p () at keyboard.c:1117<br>#13 0x000000000054f738 in recursive_edit_1 () at=
 keyboard.c:723<br>#14 0x000000000054f8cc in Frecursive_edit () at keyboard=
.c:794<br>#15 0x000000000054d706 in main (argc=3D5, argv=3D0x7fffffffe6a8) =
at emacs.c:1643<br><br>Somehow, the argument to Fcopy_sequence was changed =
while concat was<br>underway. Further investigation indicates that<br>windo=
w-configuration-change-hook was called in the middle of concat:<br><br>Brea=
kpoint 8, run_window_configuration_change_hook (f=3D0x1718660) at window.c:=
3141<br>3141=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ptrdiff_t count =3D SPECPDL_INDE=
X ();<br>#0=C2=A0 run_window_configuration_change_hook (f=3D0x1718660) at w=
indow.c:3141<br>#1=C2=A0 0x0000000000425882 in adjust_frame_size (f=3D0x171=
8660, new_width=3D824, new_height=3D516, inhibit=3D5, pretend=3Dfalse, para=
meter=3D13152) at frame.c:599<br>#2=C2=A0 0x0000000000422c01 in change_fram=
e_size_1 (f=3D0x1718660, new_width=3D824, new_height=3D516, pretend=3Dfalse=
, delay=3Dfalse, safe=3Dfalse, pixelwise=3Dtrue) at dispnew.c:5507<br>#3=C2=
=A0 0x0000000000422c57 in change_frame_size (f=3D0x1718660, new_width=3D824=
, new_height=3D516, pretend=3Dfalse, delay=3Dfalse, safe=3Dfalse, pixelwise=
=3Dtrue) at dispnew.c:5539<br>#4=C2=A0 0x0000000000422a2f in do_pending_win=
dow_change (safe=3Dfalse) at dispnew.c:5465<br>#5=C2=A0 0x0000000000536c22 =
in xg_frame_resized (f=3D0x1718660, pixelwidth=3D842, pixelheight=3D518) at=
 gtkutil.c:924<br>#6=C2=A0 0x0000000000518a9f in handle_one_xevent (dpyinfo=
=3D0x15b07d0, event=3D0x7fffffff7210, finish=3D0xbfaacc, hold_quit=3D0x7fff=
ffff74a0) at xterm.c:8294<br>#7=C2=A0 0x0000000000516a69 in event_handler_g=
dk (gxev=3D0x7fffffff7210, ev=3D0x568b410, data=3D0x0) at xterm.c:7294<br>#=
8=C2=A0 0x00007ffff6769661 in gdk_event_apply_filters (xevent=3Dxevent@entr=
y=3D0x7fffffff7210, event=3Devent@entry=3D0x568b410, window=3Dwindow@entry=
=3D0x0) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkeventsource.c:81<br>#9=
=C2=A0 0x00007ffff6769929 in gdk_event_source_translate_event (xevent=3D0x7=
fffffff7210, event_source=3D0x14e4090) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/=
x11/gdkeventsource.c:195<br>#10 _gdk_x11_display_queue_events (display=3D0x=
1506050) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkeventsource.c:338<br>#1=
1 0x00007ffff673cae9 in gdk_display_get_event (display=3Ddisplay@entry=3D0x=
1506050) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/gdkdisplay.c:340<br>#12 0x0000=
7ffff67696e2 in gdk_event_source_dispatch (source=3D&lt;optimized out&gt;, =
callback=3D&lt;optimized out&gt;, user_data=3D&lt;optimized out&gt;) at /tm=
p/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkeventsource.c:360<br>#13 0x00007ffff50=
bac3d in g_main_dispatch (context=3D0x14f1f80) at /tmp/buildd/glib2.0-2.44.=
1/./glib/gmain.c:3122<br>#14 g_main_context_dispatch (context=3Dcontext@ent=
ry=3D0x14f1f80) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737<br>#15 0x=
00007ffff50baf20 in g_main_context_iterate (context=3Dcontext@entry=3D0x14f=
1f80, block=3Dblock@entry=3D1, dispatch=3Ddispatch@entry=3D1, self=3D&lt;op=
timized out&gt;) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3808<br>#16 0=
x00007ffff50bafcc in g_main_context_iteration (context=3D0x14f1f80, context=
@entry=3D0x0, may_block=3Dmay_block@entry=3D1) at /tmp/buildd/glib2.0-2.44.=
1/./glib/gmain.c:3869<br>#17 0x00007ffff6be1ff5 in gtk_main_iteration () at=
 /tmp/buildd/gtk+3.0-3.16.6/./gtk/gtkmain.c:1320<br>#18 0x0000000000519220 =
in XTread_socket (terminal=3D0x11ecdd0, hold_quit=3D0x7fffffff74a0) at xter=
m.c:8644<br>#19 0x000000000055bbe2 in gobble_input () at keyboard.c:6893<br=
>#20 0x000000000055bfcc in handle_async_input () at keyboard.c:7145<br>#21 =
0x000000000055bfeb in process_pending_signals () at keyboard.c:7159<br>#22 =
0x00000000005c3d3a in Fmake_list (length=3D0, init=3D0) at alloc.c:2676<br>=
#23 0x00000000005ef6f8 in concat (nargs=3D1, args=3D0x7fffffff76e8, target_=
type=3DLisp_Cons, last_special=3Dfalse) at fns.c:642<br>#24 0x00000000005ef=
0f3 in Fcopy_sequence (arg=3D49369891) at fns.c:510<br>#25 0x00000000005572=
52 in timer_check () at keyboard.c:4569<br>#26 0x0000000000555106 in readab=
le_events (flags=3D1) at keyboard.c:3422<br>#27 0x000000000055ba2b in get_i=
nput_pending (flags=3D1) at keyboard.c:6808<br>#28 0x0000000000556a49 in sw=
allow_events (do_display=3Dfalse) at keyboard.c:4320<br>#29 0x000000000063a=
f9c in wait_reading_process_output (time_limit=3D1, nsecs=3D0, read_kbd=3D0=
, do_display=3Dfalse, wait_for_cell=3D0, wait_proc=3D0x2fd6078, just_wait_p=
roc=3D0) at process.c:4992<br>#30 0x0000000000638f6c in Faccept_process_out=
put (process=3D50159736, seconds=3D6, millisec=3D0, just_this_one=3D0) at p=
rocess.c:4241<br><br>I&#39;m not sure whether the bug is in my code (and, i=
f so, how to fix<br>it=E2=80=94if scheduling an immediate timer isn&#39;t s=
afe, what could possibly<br>be?), in Fmake_list, in QUIT, or in the X or GT=
K code, but at least<br>one of them is buggy.<br><br>M-x report-emacs-bug i=
nformation:<br><br>I have been unable, so far, to reproduce this bug reliab=
ly from `emacs<br>-Q&#39;.<br><br>In GNU Emacs 25.0.50.52 (x86_64-unknown-l=
inux-gnu, GTK+ Version 3.16.6)<br>=C2=A0of 2015-08-30<br>Repository revisio=
n: c6af816affb36d512f806725518e6e5f2353b197<br>Windowing system distributor=
 `The X.Org Foundation&#39;, version 11.0.11702000<br>System Description:=
=C2=A0=C2=A0=C2=A0 Debian GNU/Linux unstable (sid)<br><br>Configured using:=
<br>=C2=A0`configure &#39;CFLAGS=3D-O0 -g3&#39;&#39;<br><br>Configured feat=
ures:<br>XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GCONF GSETTINGS NOTIFY LIBSE=
LINUX<br>GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11<br><=
br>Important settings:<br>=C2=A0 value of $LANG: en_US.UTF-8<br>=C2=A0 loca=
le-coding-system: utf-8-unix<br><br>Major mode: Text<br><br>Minor modes in =
effect:<br>=C2=A0 diff-auto-refine-mode: t<br>=C2=A0 tooltip-mode: t<br>=C2=
=A0 global-eldoc-mode: t<br>=C2=A0 electric-indent-mode: t<br>=C2=A0 mouse-=
wheel-mode: t<br>=C2=A0 tool-bar-mode: t<br>=C2=A0 menu-bar-mode: t<br>=C2=
=A0 file-name-shadow-mode: t<br>=C2=A0 global-font-lock-mode: t<br>=C2=A0 f=
ont-lock-mode: t<br>=C2=A0 blink-cursor-mode: t<br>=C2=A0 auto-composition-=
mode: t<br>=C2=A0 auto-encryption-mode: t<br>=C2=A0 auto-compression-mode: =
t<br>=C2=A0 line-number-mode: t<br>=C2=A0 transient-mark-mode: t<br><br>Loa=
d-path shadows:<br>None found.<br><br>Features:<br>(shadow sort gnus-util m=
ail-extr emacsbug message dired format-spec<br>rfc822 mml mml-sec mm-decode=
 mm-bodies mm-encode mail-parse rfc2231<br>mailabbrev gmm-utils mailheader =
sendmail rfc2047 rfc2045 ietf-drums<br>mm-util help-fns help-mode cl-loadde=
fs pcase cl-lib mail-prsvr<br>mail-utils vc-git diff-mode easymenu easy-mmo=
de time-date mule-util<br>tooltip eldoc electric uniquify ediff-hook vc-hoo=
ks lisp-float-type<br>mwheel x-win term/common-win x-dnd tool-bar dnd fonts=
et image regexp-opt<br>fringe tabulated-list newcomment elisp-mode lisp-mod=
e prog-mode register<br>page menu-bar rfn-eshadow timer select scroll-bar m=
ouse jit-lock<br>font-lock syntax facemenu font-core frame cl-generic cham =
georgian<br>utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korea=
n<br>japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european<=
br>ethiopic indian cyrillic chinese charscript case-table epa-hook<br>jka-c=
mpr-hook help simple abbrev minibuffer cl-preloaded nadvice<br>loaddefs but=
ton faces cus-face macroexp files text-properties overlay<br>sha1 md5 base6=
4 format env code-pages mule custom widget<br>hashtable-print-readable back=
quote dbusbind inotify dynamic-setting<br>system-font-setting font-render-s=
etting move-toolbar gtk x-toolkit x<br>multi-tty make-network-process emacs=
)<br><br>Memory information:<br>((conses 16 84908 4447)<br>=C2=A0(symbols 4=
8 19432 0)<br>=C2=A0(miscs 40 43 147)<br>=C2=A0(strings 32 14795 4332)<br>=
=C2=A0(string-bytes 1 417071)<br>=C2=A0(vectors 16 11731)<br>=C2=A0(vector-=
slots 8 419664 4375)<br>=C2=A0(floats 8 138 302)<br>=C2=A0(intervals 56 225=
 13)<br>=C2=A0(buffers 976 12)<br>=C2=A0(heap 1024 19426 1811))<br><br></di=
v>

--001a1144ac34689f02051e86c67d--




Acknowledgement sent to Pip Cet <pipcet@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#21380; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Wed, 2 Sep 2015 16:15:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.