-
Notifications
You must be signed in to change notification settings - Fork 13.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bugfix: Timestamp wrapping when initializing SubscriptionInterval less than the interval time after boot #23384
Conversation
The stamp stays 0 if subscriptions are initialized less than the interval time after boot instead of wrapping the unsigned timestamp.
This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there: |
…ess than the interval time after boot (#23384) * SubscriptionInterval: ensure _last_update is never before timer start
…ess than the interval time after boot (#23384) * SubscriptionInterval: ensure _last_update is never before timer start
@dagar Do you have any idea why this change consumes so much flash (2.5kb) if I saw it correctly? It wasn't on my radar until I saw 1.15 failing and now I saw also on main it fails quite a few. How can one more branch in the code path without templating contribute to so much usage? 😱 |
I ran a bloaty compare and the if case adds ~2kb, the else case another 0.5kb 🤯 Bloaty output if case only
Bloaty output if and else case
|
I found out thanks to @niklaut 's analysis for the decompiled binary 🙏🙏 |
Here we go: #23395 I wonder how much the tradeoff for less jumps makes sense on the microcontroller and how much flash we waste by unintentionally inlining 🤔 |
…ess than the interval time after boot (PX4#23384) * SubscriptionInterval: ensure _last_update is never before timer start
Solved Problem
When debugging #23378 , the only instance where timestamps get negative/wrap the unsigned datatype was the case where
SubscriptionInterval
s are initialized less than the interval time (e.g. 1 second) after boot and hence the start of the microcontroller timer. This made the cases fail after invalid assumptions were made that this case would never normally happen without checking even once here: https://github.com/PX4/PX4-Autopilot/pull/22881/files#diff-5971d648b2b246dfb01ec5d5006b5258cfdbc41b73f50db1abe7dd5236f855e1R167-R172The change producing a few timestamps after boot that wrap was introduced here:
https://github.com/PX4/PX4-Autopilot/pull/14181/files#diff-c82d12a48f93eeb820597a14504a6a2d58cb7c09ad86d2e7da6aa6b04e144628L124-R128
and it never resulted in any problem because even across the wrapping the result of the elapsed time calculation was correct again.
Fixes #23378
Solution
The stamp stays 0 if subscriptions are initialized less than the interval time after boot instead of wrapping the unsigned timestamp.
It might not be optimal when the 64 bit time actually wraps because then for one intervals time the
_last_update
is not updated anymore but I hope that's acceptable given this should only happen after 500+k years of runtime.Changelog Entry
Alternatives
Even with this fix I highly suggest reverting the change that made elapsed time across wrapping calculations impossible: #23380
Test coverage
I ran this in SITL printing out all the
_last_update
timestamps of all instances and they do not wrap anymore shortly after boot but rather stay zero until the interval time passed once.