Timer corruption when using mgos_settimeofday after setting a MGOS_TIMER_RUN_NOW timer

[DrBomb]

Issue

If you make a call to mgos_settimeofday after setting a timer with the MGOS_TIMER_RUN_NOW flag, the timer gets a negative next_invocation value, breaking all the timers in the system. Affecting even cronjobs as well.

Sample app with reproduction steps, some background and a patch to visualize the issue is available here:

https://github.com/DrBomb/TimerCorruption

[DrBomb]

Forgot to add, the platform tested is ESP32. And I've added SNTP and WiFi in case you want to test it out with a real clock value, for which the same happens.

[DrBomb]

Upon further examination. The issue happens when the time set by mgos_settimeofday is less than the current time! Very fascinating. I assumed that the wall time was lost on software reboot, but seems like it stays across reboots!

In this case, the timer corruption happens when the set time is less than the current time while we have a pending timer.

[rojer]

ugh... another case where using wall time for timers hurts. we should really switch to uptime! ok, point taken.

[DrBomb]

@rojer Would this line change be enough as a stopgap measure to avoid this issue while the migration to uptime is done?

https://gist.github.com/DrBomb/f279be42181d1e1635a7c8b6a8e874cb#file-mgos_timers-c-L190

SNTP is emitting negative-time deltas and I believe it is still screwing up the timers on our deployments

[rojer]

pushed the uptime change. try now, it should fix the issue.