unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Pip Cet <pipcet@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 21380@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	[thread overview]
Message-ID: <CAOqdjBeqoKaE=31v8QzLcjDq0=m3ERSXx_33Zr4aZyOSxQB0aw@mail.gmail.com> (raw)
In-Reply-To: <jwv1tefo7ic.fsf-monnier+emacsbugs@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2178 bytes --]

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@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).

[-- Attachment #2: Type: text/html, Size: 2894 bytes --]

  parent reply	other threads:[~2015-09-05 16:59 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-30 12:51 bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook Pip Cet
2015-08-30 15:01 ` Eli Zaretskii
2015-08-30 15:24   ` Pip Cet
2015-08-30 15:27     ` Pip Cet
2015-08-30 16:24       ` Pip Cet
2015-08-30 18:10         ` martin rudalics
2015-08-30 18:20           ` Pip Cet
2015-08-30 19:50             ` Eli Zaretskii
2015-08-30 18:59           ` Pip Cet
2015-08-31  9:20             ` martin rudalics
2015-08-30 16:39     ` Eli Zaretskii
2015-08-30 16:42       ` Pip Cet
2015-08-30 19:44         ` Eli Zaretskii
2015-08-30 20:56           ` Pip Cet
2015-08-30 21:13             ` Pip Cet
2015-08-31 14:31             ` Eli Zaretskii
2015-09-01 10:20               ` Pip Cet
2015-09-01 15:03                 ` Eli Zaretskii
2015-09-01 15:22                   ` Pip Cet
2015-09-01 16:01                     ` Eli Zaretskii
2015-09-01 16:02                       ` Pip Cet
2015-09-01 16:23                         ` Eli Zaretskii
2015-09-02  7:02                       ` martin rudalics
2015-09-02 14:32                         ` Eli Zaretskii
2015-09-03 15:36                         ` Stefan Monnier
2015-09-05  7:38                           ` Eli Zaretskii
2015-09-05 15:18                             ` Stefan Monnier
2015-09-05 15:27                               ` Eli Zaretskii
2015-09-06 22:11                                 ` Stefan Monnier
2022-04-29 12:52                             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-29 13:40                               ` Eli Zaretskii
2022-04-29 13:44                                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-29 15:02                                   ` Pip Cet
2015-09-05 16:59                           ` Pip Cet [this message]
2015-09-06 22:22                             ` Stefan Monnier
2015-09-08 15:55                               ` Pip Cet
2015-09-01 15:14                 ` Pip Cet
2015-09-01 16:04                   ` Eli Zaretskii
2015-09-01 16:56                     ` Pip Cet
2015-09-01 17:19                       ` Eli Zaretskii
2015-09-01 20:48                         ` Pip Cet
2015-09-02 15:08                           ` Eli Zaretskii
2015-09-02 16:09                             ` Pip Cet
2015-09-02 19:13                               ` Eli Zaretskii
2015-09-02 22:08                                 ` Pip Cet
2020-09-07 17:07                           ` Lars Ingebrigtsen
2020-09-07 17:47                             ` Pip Cet
2020-09-07 19:09                             ` Eli Zaretskii
2020-09-08  9:57                               ` Lars Ingebrigtsen
2022-04-29 12:14                                 ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOqdjBeqoKaE=31v8QzLcjDq0=m3ERSXx_33Zr4aZyOSxQB0aw@mail.gmail.com' \
    --to=pipcet@gmail.com \
    --cc=21380@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).