1601796 - Negative elapsed time in the third-party-module ping

Status: RESOLVED FIXED

(Core :: mozglue, defect, P3)

Description

[Toshihito Kikuchi [:toshi]]

We can see a number of instances of the third-party-module ping have a negative number in payload.processes[PID].value.elapsed like -9,223,362,128.71, which is unexpected. Probably it's caused by int64 overflow (-9223372036854775808 = 80000000`00000000) somewehere.

Comment 1

[Toshihito Kikuchi [:toshi]]

Attachment: Bug 1601796 - Use GetSystemTimePreciseAsFileTime instead of GetSystemTime+SystemTimeToFileTime. r=froydnj

GetProcessTimes is based on QPC, while GetSystemTime is based on clock
interruption whose accuracy is lower than QPC. This means in a process's early
stage, GetSystemTime may return a timestamp earlier than creation timestamp.
If this happens we'll have a negative process uptime.

Win8+ has a handy API GetSystemTimePreciseAsFileTime that solves everything.

On Win7, GetSystemTimeAsFileTime still solves this issue. In the worst case,
it returns the exact same timestamp as process creation, but it's ok.

Because the system time is stored as a FILETIME in KUSER, converting it to
a SYSTEMTIME with GetSystemTime drops accuracy. We shoudl avoid it unless
needed.

This patch also moves the call to GetProcessTimes before getting the current
timestamp in case clock interruption happens in between those two function calls.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7e20358019ae
Use GetSystemTimePreciseAsFileTime instead of GetSystemTime+SystemTimeToFileTime.   r=mayhemer,aklotz

Comment 3

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/7e20358019ae