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

[ndame]

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

The negative timer problem happened to me today.

I checked and I also had t as the first element of the timer structure.

I'm quite positive it happened when there was an error when running

the timer function.

Is it possible there is no unwind-protect-like code around running

the timer and that's why the first element is not set t when the

timer function has an error.