GitLab

When processing systrace events, a decimal timestamp in seconds like
"123.456000" was being parsed as a pair of int32_t's separated by the
dot, and then converted into an microsecond integer value by scaling the
integer seconds value appropriately, and adding the fractional part.

However if the number of seconds was large enough, the multiplication
would overflow an int32_t, resulting in an incorrect timestamp being
computed, which then caused those events to be filtered out as they were
not in the expected range.

The fix was to simply implicitly convert to an int64_t to hold the
result of the multiplication.

This was enough to fix the bug.

However the parsing makes a potentially unsafe and unchecked assumption
that the number of digits after the decimal point is always the expected
amount. If it was ever different, the computed timestamps would be
incorrect.

I also went and corrected most of the code to use a uniform type for the
timestamp of uint64_t, as parts of the code used int64_t, and other
parts used double. Doubles are still used however for JSON serialization
and deserialization.

To verify the timestamp parsing, I added some specific tests to the unit
test.

TEST=Unit tests pass, arc-graphics-tracing works
BUG=b:132907802

Change-Id: I8608fae90eb4708f5c6abd7088ca4b859aeab91f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1616325Reviewed-by: Yury Khmel <khmel@chromium.org>
Commit-Queue: Lloyd Pique <lpique@chromium.org>
Cr-Commit-Position: refs/heads/master@{#660971}