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