Derek Xu
1d69b0b980
This change makes it so that when the VM detects that a timer is at least 100 ms overdue, it sends a warning in a VM Service event on the 'Timer' stream. TEST=Built an Android Flutter app with a modified Engine that contained a `sleep` call in `eventhandler_linux.cc` and confirmed that the warning event got sent, built an iOS Flutter app with a modified Engine that contained a `sleep` call in `eventhandler_macos.cc` and verified that the warning event got sent, pkg/vm_service/test/overdue_timer_detection_test CoreLibraryReviewExempt: This CL does not include any core library API changes, only VM Service implementation changes. Change-Id: Ie8db047116b7f63cfb5413f763eaf56c7bdd6975 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/409500 Reviewed-by: Ben Konyi <bkonyi@google.com> Commit-Queue: Derek Xu <derekx@google.com>
2.2 KiB
Detecting Bugs in the Implementation of Timers
When an app is connected to DevTools, a message will appear in the Logging view of DevTools whenever a timer in the app fires at least 100 ms late.
As the messages in the screenshot state, the appearance of these messages does not necessarily mean that there is a bug in the implementation of timers. Timers can be blocked from firing for other reasons. A stretch of uninterruptible synchronous operations can block asynchronous operations, or an app can be frozen by the OS to conserve resources. When "late timer" messages appear, these other causes must be ruled out before before suspecting that there is a bug in the implementation of timers.
Be wary of the fact that it is possible for a bug in the implementation of timers to manifest only by increasing the delay length of timers that would have also been delayed under normal circumstances. For example, this bug in the implementation of timers on Android only manifested after a given Android app was put into and then taken out of the Android cached apps freezer. One would have had to join the information logged in DevTools with information logged by the Android platform to discover this bug. The following is an explanation of how this could have been done.
Consider an app that was put into and taken out of the cached apps freezer. The
times at which the app was put into and taken out of the cached apps freezer
will be available in logcat.
This link
explains how to find those times. Let those times be f_in and f_out. There
will be messages in DevTools that say "A timer was supposed to fire x_i ms
ago, but just fired now...". The time at which each message was logged will also
be shown in DevTools; let these time be m_i. If a message exists such that
(f_in <= m_i - x_i <= f_out) AND (x_i >= f_out - f_in), and other
asynchronous operations blockers can be ruled out, then it means that there is a
bug in the implementation of timers.