Overhauling how we measure uptime in crashes

[Gabriele Svelto]

[cross-posting to dev-tech-gfx and crash-reporting-wg]

Hello all,
I recently noticed that we have two different uptime measures in crashes
which make things confusing. For starters what Socorro calls "Uptime" in
a crash Details' tab is computed by subtracting the time of application
startup from the time when the crash occurred. Because it uses absolute
time values it can be inconsistent due to clock jumps. Then we have the
confusingly-named UptimeTS field which is a measure of the main process'
uptime. It isn't consistent across all platforms (Windows' includes
standby time in this measure, Linux and macOS do not). It's original
goal was to provide a way to correlate events recorded using TimeStamp
durations (see bug 1240160 [1]).

I'd like to overhaul these values to make them more useful and less
confusing so I propose the following change: the UptimeTS annotation is
removed and replaced with a ProcessUptime annotation that indicates the
uptime of the **crashed process** (not just the main process).
Internally this would still use the TimeStamp class to ensure it's
counted monotonically. This would then be surfaced in Socorro in a more
friendly way so that one can immediately tell it apart from the
application uptime.

As for the "regular" uptime I'm wondering if it would make sense to
remove the StartupTime and CrashTime annotations and replace them with a
single Uptime field that's also recorded monotonically. This would
require more surgery on Socorro's side and I don't know if we only care
about uptime or if the absolute startup and crash times have some other
value during crash analysis.

WDYT?

Gabriele

[1] crash reports and TimeStamp
https://bugzilla.mozilla.org/show_bug.cgi?id=1240160

[Gabriele Svelto]

Thanks but this was more about changing the external presentation of
those values, the implementation details are something we can change
under the hood as long as external semantics are guaranteed. If bug
1685502 lands - and that's already got my r+ - we can use
AwakeTimeStamp where it makes sense.

Note that in this particular case I'd keep the uptimes on a monotonic
timer that includes standby time (i.e. the opposite of AwakeTimeStamp)
because that's important to know if certain events that are bound to
timers have executed - for example if Firefox has been running for more
than a day regardless of standby time. Funnily enough we don't have a
class with those guarantees yet, precisely because TimeStamp does
different things on different platforms. This is obviously an additional
argument in favor of different timestamp classes with consistent
behavior across platforms.

Gabriele

> Indeed. If more resolution is required than what's available on Windows
> ([0] for extensive details, but generally ~16ms except when playing back
> media, in Firefox), it's quite easy to do, but not done.
>
> TimeStamp is known unsuitable for this kind of task, and the code in gfx
> that would like to correlate is probably easily moved to Uptime.cpp,
> compared to the alternative [1].
>
> HTH,
> Paul.
>
> [0]:
> https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/
> <https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/>
> : the behaviour changed on recent versions of Windows.
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1702521
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1702521>
>
> On Mon, Apr 19, 2021 at 3:58 PM Chris H-C <chu...@mozilla.com
> <mailto:chu...@mozilla.com>> wrote:
>
> I recommend asking :padenot (+Cc) if the cross-platform process
> uptime clock added in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1205985
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1205985> is a good fit
> for this use case.
>
> It'd be UptimeTS, but consistent.
>
> :chutten

> <https://bugzilla.mozilla.org/show_bug.cgi?id=1240160>
>
> --
> You received this message because you are subscribed to the
> Google Groups "stab...@mozilla.org
> <mailto:stab...@mozilla.org>" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to stability+...@mozilla.org
> <mailto:stability%2Bunsu...@mozilla.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.org/d/msgid/stability/a7355cf5-6586-80c9-da8d-c32f7447384d%40mozilla.com
> <https://groups.google.com/a/mozilla.org/d/msgid/stability/a7355cf5-6586-80c9-da8d-c32f7447384d%40mozilla.com>.
>