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

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>, 21380 <at> debbugs.gnu.org
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 part 1 (text/plain, inline)]

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 <monnier <at> 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 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).

[Message part 2 (text/html, inline)]

Previous Next

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