arc: Fix arc-graphics-tracing timestamp parsing
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}
Showing
Please register or sign in to comment