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: Sat, 5 Sep 2015 16:59:06 +0000 Message-ID: References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> <55E69F07.9060006@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11402ad22abe53051f02efcf X-Trace: ger.gmane.org 1441472423 13077 80.91.229.3 (5 Sep 2015 17:00:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Sep 2015 17:00:23 +0000 (UTC) Cc: 21380@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 05 19:00:15 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 1ZYGp4-0004QA-FI for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Sep 2015 19:00:14 +0200 Original-Received: from localhost ([::1]:41763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYGp4-0007Qh-Jd for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Sep 2015 13:00:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYGoz-0007Or-DG for bug-gnu-emacs@gnu.org; Sat, 05 Sep 2015 13:00:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZYGow-0000PM-6n for bug-gnu-emacs@gnu.org; Sat, 05 Sep 2015 13:00:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYGow-0000Nr-2F for bug-gnu-emacs@gnu.org; Sat, 05 Sep 2015 13:00:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZYGov-0004O9-0R for bug-gnu-emacs@gnu.org; Sat, 05 Sep 2015 13:00:05 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Sep 2015 17:00:04 +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.144147235016780 (code B ref 21380); Sat, 05 Sep 2015 17:00:04 +0000 Original-Received: (at 21380) by debbugs.gnu.org; 5 Sep 2015 16:59:10 +0000 Original-Received: from localhost ([127.0.0.1]:50078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYGo1-0004MZ-Ga for submit@debbugs.gnu.org; Sat, 05 Sep 2015 12:59:10 -0400 Original-Received: from mail-io0-f195.google.com ([209.85.223.195]:35961) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYGnz-0004MR-Fk for 21380@debbugs.gnu.org; Sat, 05 Sep 2015 12:59:08 -0400 Original-Received: by ioiz6 with SMTP id z6so5517172ioi.3 for <21380@debbugs.gnu.org>; Sat, 05 Sep 2015 09:59:06 -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=anP860I9fd2xJjC6KKNABBfjQtPVTU21H/3FVI5qGWg=; b=SjnTy6r7XQmmHYORDRaUPb4AbfjkoE2BYUeNI7SqiPjFt3FmyeWvQQWCx9g6qojB+w FS2W7GQwI6CAbRgIQ8zXVOMtUfDwB5G2FDeGrCw7Dm0lp3007pHAhSmnfrNv95bg5UxX v8oa2Av5g4Y51VHFuuMDls5ThRYSXGnDXyPk1un07SENvaT/Uglh04HhJNiEKxq2h94a UvvKqpFj6Ldf32s6glQ3HjKUQjLYf5RGwJ1bltzbIi6UIHvXwfpsUKG4q3ew+wd/QhR6 nJPZKQei/qJkdZQ2Q6+/NeahFu/vgNQhW+Y5dsatrn+nUhLYENkzM1+SC1pJtaPSTrtR 2NAw== X-Received: by 10.107.162.205 with SMTP id l196mr17322364ioe.3.1441472346502; Sat, 05 Sep 2015 09:59:06 -0700 (PDT) Original-Received: by 10.79.78.66 with HTTP; Sat, 5 Sep 2015 09:59:06 -0700 (PDT) In-Reply-To: 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:106181 Archived-At: --001a11402ad22abe53051f02efcf Content-Type: text/plain; charset=UTF-8 I think that's a good idea, but there's one corner case that, I think, we should think about: a timer deleting the next timer from the list. If we keep the code in timer.el that says: (defun cancel-timer (timer) "Remove TIMER from the list of active timers." (timer--check timer) (setq timer-list (delq timer timer-list)) (setq timer-idle-list (delq timer timer-idle-list)) nil) then that delq might, in some circumstances, modify the list we're working on. I'm not sure whether it's okay, performance-wise, to replace delq by remq here. Is cancelling one timer from another timer's code something that should ever have well-defined effects (I strongly suspect the answer is "Don't do that")? I confess I do not know whether delq is guaranteed only to modify the list in ways that "make sense" (the current implementation does, but it also doesn't appear to QUIT at all, so maybe it should be modified anyway...). On Thu, Sep 3, 2015 at 3:36 PM, Stefan Monnier wrote: > AFAICT these lists are only ever side-effected by timer.el's > timer--activate, which has a special `reuse-cell' argument just to be > able to do that. > I think delq also side-effects them. And, of course, "(setq timer-list nil)", which is what I tend to do when I've added a silly timer that does something bizarre and makes Emacs unusable :-) Maybe we should go back to bugs #12447 and #12326 and see if just > removing the "reuse-cell" code (and the Fcopy_sequence(s)) fixes the > problem as well. > I haven't tested this, but I think it would. I still think the underlying problem here is not having a well-defined rule for when QUIT is allowed to call Lisp code. (Eli correctly objected to my initial idea that the rule should be "never", but I still think it should be "much less often than we currently do". I've performed some very boring and somewhat tedious semi-automated call chain analysis to get a better idea of what the current state of things is, and so far the results appear consistent with my idea that QUIT shouldn't call hooks, but should be able to call isolated functions implemented in Lisp, such as those used for relative font sizing). --001a11402ad22abe53051f02efcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that's a good idea, but there's one c= orner case that, I think, we should think about: a timer deleting the next = timer from the list. If we keep the code in timer.el that says:

(def= un cancel-timer (timer)
=C2=A0 "Remove TIMER from the list of activ= e timers."
=C2=A0 (timer--check timer)
=C2=A0 (setq timer-list (= delq timer timer-list))
=C2=A0 (setq timer-idle-list (delq timer timer-i= dle-list))
=C2=A0 nil)

then that delq might, in some circum= stances, modify the list we're working on. I'm not sure whether it&= #39;s okay, performance-wise, to replace delq by remq here. Is cancelling o= ne timer from another timer's code something that should ever have well= -defined effects (I strongly suspect the answer is "Don't do that&= quot;)? I confess I do not know whether delq is guaranteed only to modify t= he list in ways that "make sense" (the current implementation doe= s, but it also doesn't appear to QUIT at all, so maybe it should be mod= ified anyway...).

On Thu, Sep 3, 2015 at 3:36 PM, Stefan M= onnier <monnier@iro.umontreal.ca> wrote:
AFAICT these lists are only ever side-effected by timer= .el's
timer--activate, which has a special `reuse-cell' argument just to be able to do that.

I think delq also side= -effects them. And, of course, "(setq timer-list nil)", which is = what I tend to do when I've added a silly timer that does something biz= arre and makes Emacs unusable :-)

Maybe we should go back to bugs #12447 and #12326 and see if just
removing the "reuse-cell" code (and the Fcopy_sequence(s)) fixes = the
problem as well.

I haven't tested t= his, but I think it would. I still think the underlying problem here is not= having a well-defined rule for when QUIT is allowed to call Lisp code. (El= i correctly objected to my initial idea that the rule should be "never= ", but I still think it should be "much less often than we curren= tly do". I've performed some very boring and somewhat tedious semi= -automated call chain analysis to get a better idea of what the current sta= te of things is, and so far the results appear consistent with my idea that= QUIT shouldn't call hooks, but should be able to call isolated functio= ns implemented in Lisp, such as those used for relative font sizing).
--001a11402ad22abe53051f02efcf--