24.3.50; Timer firing after being canceled

24.3.50; Timer firing after being canceled

[Michael Heerdegen]

Hi,

This report is about the following problem (bug) raised in
gnu.emacs.devel by Tomohiro Matsuyama:

,----------------------------------------------------------------------
| Hi,
| 
| I have found a problem that cancel-timer will not work in a particular
| situation where the timer takes more time to execute than a
| rescheduling interval of the timer.  Here is the reproducible code:
| 
|     (setq my-timer
|           (run-with-timer
|            nil 0.1
|            (lambda ()
|              (when my-timer
|                (cancel-timer my-timer)
|                (setq my-timer nil)
|                (sit-for 0.3)))))
| 
| After evaluating this code several times, you may see "zombie" timers
| in timer-list, though the code intends to keep at most one timer.
`----------------------------------------------------------------------

I can reproduce this problem.  And I have a test case that proves that
timers that have been canceled (i.e., removed from `timer-list') are
still called from C:

--8<---------------cut here---------------start------------->8---
(defvar my-timer nil)

(defun start-the-timer ()
  (interactive)
  (setq my-timer
        (run-with-timer
         0 0.1
         (lambda ()
           (cancel-timer my-timer)
           (sit-for 0.3)))))

(advice-add 'timer-event-handler :before
            (lambda (timer)
              (when (and (eq timer my-timer)
                         (not (memq my-timer timer-list)))
                (message "Why is this ever reached?"))))
--8<---------------cut here---------------end--------------->8---

If you call `start-the-timer', you get the message "Why is this ever
reached?" over and over.  This obviously should not happen.


Thanks,

Michael.



In GNU Emacs 24.3.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2)
 of 2013-04-04 on dex, modified by Debian
 (emacs-snapshot package, version 2:20130403-1)
Windowing system distributor `The X.Org Foundation', version 11.0.11204000
System Description:	Debian GNU/Linux 7.0 (wheezy)

Configured using:
 `configure --build x86_64-linux-gnu --host x86_64-linux-gnu
 --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var --infodir=/usr/share/info --mandir=/usr/share/man
 --with-pop=yes
 --enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/24.3.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3.50/site-lisp:/usr/share/emacs/site-lisp
 --without-compress-info --with-crt-dir=/usr/lib/x86_64-linux-gnu/
 --with-x=yes --with-x-toolkit=gtk3 --with-imagemagick=yes
 CFLAGS='-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2'
 CPPFLAGS='-D_FORTIFY_SOURCE=2' LDFLAGS='-g -Wl,--as-needed
 -znocombreloc''

Important settings:
  value of $LC_ALL: de_DE.utf8
  value of $LC_TIME: C
  value of $LANG: de_DE.utf8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Dired by name

Re: 24.3.50; Timer firing after being canceled

[Stefan Monnier]

> This report is about the following problem (bug) raised in
> gnu.emacs.devel by Tomohiro Matsuyama:

AFAICT you sent it to emacs-devel rather than to bug-gnu-emacs, so it's
not "a report".

> I can reproduce this problem.  And I have a test case that proves that
> timers that have been canceled (i.e., removed from `timer-list') are
> still called from C:
> --8<---------------cut here---------------start------------->8---
> (defvar my-timer nil)
> (defun start-the-timer ()
>   (interactive)
>   (setq my-timer
>         (run-with-timer
>          0 0.1
>          (lambda ()
>            (cancel-timer my-timer)
>            (sit-for 0.3)))))

> (advice-add 'timer-event-handler :before
>             (lambda (timer)
>               (when (and (eq timer my-timer)
>                          (not (memq my-timer timer-list)))
>                 (message "Why is this ever reached?"))))
> --8<---------------cut here---------------end--------------->8---
> If you call `start-the-timer', you get the message "Why is this ever
> reached?" over and over.  This obviously should not happen.

IIUC this is a consequence of the patch below.


        Stefan


revno: 110138
fixes bugs: http://debbugs.gnu.org/12447 http://debbugs.gnu.org/12326
committer: Eli Zaretskii <eliz@gnu.org>
branch nick: trunk
timestamp: Sat 2012-09-22 16:16:03 +0300
message:
  Fix bugs #12447 and #12326 with infloop causes by idle timers, update docs.
  
   src/keyboard.c (timer_check_2): Move calculation of 'timers' and
   'idle_timers' from here ...
   (timer_check): ... to here.  Use Fcopy_sequence to copy the timer
   lists, to avoid infloops when the timer does something stupid,
   like reinvoke itself with the same or smaller time-out.
  
   lisp/emacs-lisp/timer.el (run-with-idle-timer)
   (timer-activate-when-idle): Warn against reinvoking an idle timer
   from within its own timer action.
  
   doc/lispref/os.texi (Idle Timers): Warn against reinvoking an idle timer
   from within its own timer action.

`report-emacs-bug' and mail-user-agent (was: 24.3.50; Timer firing after being canceled)

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> AFAICT you sent it to emacs-devel rather than to bug-gnu-emacs, so it's
> not "a report".

Oops.  I have mail-user-agent == 'gnus-user-agent.  When I call
`report-emacs-bug' while Gnus is running, the TO header of the bug
report will not be the bug address, but some mailing list currently
visited.

That's not good.  I'll try to find out why this happens.


Regards,

Michael.

Re: `report-emacs-bug' and mail-user-agent

[Stefan Monnier]

> Oops.  I have mail-user-agent == 'gnus-user-agent.  When I call
> `report-emacs-bug' while Gnus is running, the TO header of the bug
> report will not be the bug address, but some mailing list
> currently visited.

Sounds like a bug.

> That's not good.  I'll try to find out why this happens.

Please do,


        Stefan

Re: `report-emacs-bug' and mail-user-agent

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > Oops.  I have mail-user-agent == 'gnus-user-agent.  When I call
> > `report-emacs-bug' while Gnus is running, the TO header of the bug
> > report will not be the bug address, but some mailing list
> > currently visited.

>> I'll try to find out why this happens.

Hope I didn't send any nonsense bug reports while debugging... ;-)

Call tree:

M-x report-emacs-bug
--> compose-mail
--> (get mail-user-agent 'composefunc) == 'gnus-msg-mail
--> (gnus-setup-message 'message
	(message-mail to subject other-headers continue
		      nil yank-action send-actions return-action))

The macro `gnus-setup-message' binds `#:group' to the value of
gnus-newsgroup-name, which is "nntp+Gmane:gmane.emacs.devel" in my test
case.

Then it does this:

(add-hook 'message-mode-hook
          (if (memq ,config '(reply-yank reply))
              (lambda ()
                (gnus-configure-posting-styles ,group))
            (lambda ()
              ;; There may be an old " *gnus article copy*" buffer.
              (let (gnus-article-copy)
                (gnus-configure-posting-styles ,group)))))

Indeed, I have this element in `gnus-posting-styles':

("\\(?:\\(?:g\\(?:\\(?:mane\\|nu\\)\\.emacs\\.devel\\)\\)\\)\\'"
  (TO "emacs-devel@gnu.org")
  (BCC #1="michael_heerdegen@web.de")
  . #2=((FCC nil)))

mainly because I read emacs-devel as a group, but want to reply always
to the mailing list.  (I know about S L, but I want to be able to use
the standard reply commands.  Please tell me if that's a bad idea.)

Yeah, and at the end, running `message-mode-hook' changes the TO field
according to the posting style via `gnus-configure-posting-styles'.

I guess binding `gnus-inhibit-posting-styles' to nil somewhere would
help, but I'm no expert for Gnus (and for mail, in general).

What can I/we do?


Regards,

Michael.

Re: `report-emacs-bug' and mail-user-agent

[Stefan Monnier]

> I guess binding `gnus-inhibit-posting-styles' to nil somewhere would
> help, but I'm no expert for Gnus (and for mail, in general).
> What can I/we do?

Please report it as a bug.  Some of your explanation didn't make sense
to me, but the Gnus guys should be able to understand it.


        Stefan

Re: `report-emacs-bug' and mail-user-agent

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Please report it as a bug.

Done - bug#14166.


Thanks,

Michael.