From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook Date: Sat, 05 Sep 2015 10:38:53 +0300 Message-ID: <83a8t18gdu.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1441438879 12419 80.91.229.3 (5 Sep 2015 07:41:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Sep 2015 07:41:19 +0000 (UTC) Cc: pipcet@gmail.com, 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 09:41:00 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 1ZY847-0008VP-4W for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Sep 2015 09:39:11 +0200 Original-Received: from localhost ([::1]:38241 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZY846-0004lk-I2 for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Sep 2015 03:39:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZY841-0004jz-LL for bug-gnu-emacs@gnu.org; Sat, 05 Sep 2015 03:39:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZY83y-0002Zk-Ep for bug-gnu-emacs@gnu.org; Sat, 05 Sep 2015 03:39:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57129) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZY83y-0002Z2-CR for bug-gnu-emacs@gnu.org; Sat, 05 Sep 2015 03:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZY83y-0004Qm-2O for bug-gnu-emacs@gnu.org; Sat, 05 Sep 2015 03:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Sep 2015 07:39: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.144143873317018 (code B ref 21380); Sat, 05 Sep 2015 07:39:01 +0000 Original-Received: (at 21380) by debbugs.gnu.org; 5 Sep 2015 07:38:53 +0000 Original-Received: from localhost ([127.0.0.1]:49339 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZY83o-0004QQ-H1 for submit@debbugs.gnu.org; Sat, 05 Sep 2015 03:38:52 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:38401) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZY83k-0004QF-PC for 21380@debbugs.gnu.org; Sat, 05 Sep 2015 03:38:50 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NU700M000E3YZ00@mtaout29.012.net.il> for 21380@debbugs.gnu.org; Sat, 05 Sep 2015 10:39:04 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NU700HW8193HA70@mtaout29.012.net.il>; Sat, 05 Sep 2015 10:39:04 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il 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:106166 Archived-At: > From: Stefan Monnier > Cc: Eli Zaretskii , Pip Cet , > 21380@debbugs.gnu.org > Date: Thu, 03 Sep 2015 11:36:44 -0400 > > >> 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. > > That'd be OK, yes. I believe the currently preferred solution is to block input and atimers while copying the timer lists to local copies. Are you okay with that? > This said, maybe an even better solution would be to avoid the copy > altogether. > > 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'm not completely sure why we do it this way, but my naive > understanding is the following: > - For historical reasons of limited resources, timer.el tries hard to > avoid allocating cons cells. > - Then many years later we found a problem with this cell-reuse and > circumvented it by copying the whole list all the time. > - So we end up working hard to avoid allocating a couple cells on one > side, only to end up allocating many more on the other. > > 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'm not sure I understand this plan. Are you saying that consing a new list in timer--activate, instead of reusing an existing cell, will avoid the need to wok on a copy of the timer's list when invoking the timer callbacks? If so, I'm probably missing something here, because timer--activate will update the timer list variable anyway, and we have the same problem, whereby the list changes under our feet, back again. IOW, if some Lisp run by a timer callback ends up doing (directly or indirectly) something like (setq timer-list (cons my-new-timer timer-list)) doesn't it mean the value of Vtimer_list in C seen by timer_check changes as well that very moment? Not to mention the fact that with timers firing every several tens of ms, something we've seen while discussing these bugs, allocating a couple of cells each time might cause a lot of consing per second, which in turn causes GC, which slows down everything.