From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook Date: Sun, 30 Aug 2015 20:56:33 +0000 Message-ID: References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113ed2f85121d9051e8d8d49 X-Trace: ger.gmane.org 1440968243 15768 80.91.229.3 (30 Aug 2015 20:57:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Aug 2015 20:57:23 +0000 (UTC) Cc: 21380@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 30 22:57:13 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZW9f6-0004qy-M1 for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Aug 2015 22:57:12 +0200 Original-Received: from localhost ([::1]:60708 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZW9f6-0007HG-3t for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Aug 2015 16:57:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZW9ez-0007GF-9S for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 16:57:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZW9ew-00007M-2L for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 16:57:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZW9ev-000075-VE for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 16:57:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZW9ev-00069j-Q8 for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 16:57:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Aug 2015 20:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21380 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21380-submit@debbugs.gnu.org id=B21380.144096819723610 (code B ref 21380); Sun, 30 Aug 2015 20:57:01 +0000 Original-Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 20:56:37 +0000 Original-Received: from localhost ([127.0.0.1]:43121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW9eW-00068i-ID for submit@debbugs.gnu.org; Sun, 30 Aug 2015 16:56:37 -0400 Original-Received: from mail-io0-f180.google.com ([209.85.223.180]:33166) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW9eU-00068Z-J2 for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 16:56:35 -0400 Original-Received: by iods203 with SMTP id s203so139740119iod.0 for <21380@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== X-Received: by 10.107.132.139 with SMTP id o11mr21144847ioi.3.1440968193677; Sun, 30 Aug 2015 13:56:33 -0700 (PDT) Original-Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 13:56:33 -0700 (PDT) In-Reply-To: <83h9ng1ryx.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:105992 Archived-At: --001a113ed2f85121d9051e8d8d49 Content-Type: text/plain; charset=UTF-8 On Sun, Aug 30, 2015 at 7:44 PM, Eli Zaretskii 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
On Sun, Aug 30, 2015 at 7:44 PM, Eli Zaretskii <eliz@gnu.org= > wrote:
> I'm n= ot 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 segfa= ult.

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'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't blocked input. (As in my example below)

I really don'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?

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

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

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

(while t
=C2=A0 (copy-sequence timer-list)
=C2=A0 (acce= pt-process-output nil 0)
=C2=A0 )

=C2=A0- interrupt and set a breakpoint with "b Fmake_sequence if !in= put_blocked_p()".
=C2=A0- wait for breakpoint to be hit, verify th= at concat's args[0] is equal to Vtimer_list.
=C2=A0- resize the X window
= =C2=A0- continue in gdb
=C2=A0- segfaul= t

As far as I can tell, that should= be reproducible. Also as far as I can tell, it's merely a matter of lu= ck 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 anoth= er bug for it if that's the way you prefer things.
--001a113ed2f85121d9051e8d8d49--