bug#39824: 26.2; timers sometimes stop working when coming back from sleep

[Eli Zaretskii]

> From: Gijs Hillenius <gijs@hillenius.net>
> Date: Tue, 24 Mar 2020 09:27:28 +0100
> 
> Since Sunday, I've been running emacs¹ from GDB, but there is nothing
> much to report. At startup, init.el sets  (run-at-time "10:35" 21600
> 'org-mobile-push). It ran on Sunday, but not on Monday (yesterday) -
> despite a good night's sleep.
> 
> Today (Tuesday), M-x timer-list shows:
> 
>       -59170.00   360.00 org-mobile-push
> 
> and from describe-variable timer-list :
> 
> ([t 24184 55076 0 21600 org-mobile-push nil nil 0]

The time of this timer is 23-Mar-2020 16:35 +0100.  This probably
means the timer did run at 10:35 that day, but you seem to say it
didn't.  Are you sure?  If it didn't run, we might have 2 mysteries
here instead of just one (the second one being how come the timer
didn't run, but the time it should run was updated).

Anyway, the real problem is that t in the first element of the vector.
It means the timer will never be run, because t means "running now",
something that should only be seen by code that is directly or
indirectly called by the timer function itself.  So it should never be
seen when you examine timer-list via M-: etc.

When Emacs finds a timer which is "ripe", i.e. its time has passed, it
updates its next time, then marks it with that t, then calls the timer
function, then replaces t with nil if the timer is to be repeated (as
it is in this case).  So the main question to be answered is: how come
that t remained in the timer?  I looked at timer-event-handler, the
function we call to run the timer, and didn't see there any way we
could fail to update the timer with nil after its function returns,
but I'm probably missing something because it factually did happen.

Can you instrument timer-event-handler, such that it will record in
some buffer everything that happens with the timer that calls
org-mobile-push?  In particular, is it possible that you put the
machine to sleep while the timer is running?  If so, what happens then
(I don't know how your system deals with sleep, and what do running
programs do during the sleep time)?  With such instrumentation in
place, when this problem happens next, we might get some idea
regarding what causes this strange situation.

Thanks.