Revision range first seen: ???? (but a long time)

Example: https://luci-milo.appspot.com/buildbot/chromium.perf/Mac%20Air%2010.11%20Perf/1160, see battor.trivial_pages and battor.trivial_pages.reference

Both of these benchmarks failed very quickly because the attached BattOrs need to be reset. 

Digging into battor.trivial_pages (http://bit.ly/2vDn1Qc), the first log line looks like:

-----------------------------------------------------------------
(WARNING) 2017-08-15 20:00:20,200 desktop_browser_finder.FindAllAvailableBrowsers:171  Chrome build location for mac_x86_64 not found. Browser will be run without Flash.
-----------------------------------------------------------------

The end of the log looks like:

-----------------------------------------------------------------
(INFO) 2017-08-15 20:01:47,038 cloud_storage.Insert:377  Uploading /b/s/w/itT1LWMF/tmp7uruIS.png to gs://chrome-telemetry-output/profiler-file-id_0-2017-08-15_20-01-4792731.png
View generated profiler files online at https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/profiler-file-id_0-2017-08-15_20-01-4792731.png for page TrivialScrollingPageSharedPageState
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ]  TrivialScrollingPageSharedPageState

1 FAILED TEST

View result at file:///b/s/w/itT1LWMF/tmph6VKfctelemetry/results-chart.json
View result at file:///b/s/w/itT1LWMF/tmph6VKfctelemetry/test-results.json
-----------------------------------------------------------------

Based on the logging, you can reasonably infer that the test took about 1m47s to fail. However, swarming doesn't corroborate this: it says:

Started:   8/15/2017, 11:00:06 PM (EDT)
Completed: 8/16/2017, 12:01:49 AM (EDT)

In otherwise, swarming says that the task takes a full hour to fail (!), and is eventually killed a by a swarming shard timeout. Looking at other benchmark runs on the same bot (build125-b1) seems to corroborate swarming's story: the next benchmark to run on the bot is blink_perf.layout, which has a "pending" time of 2h4m. This is suspiciously close to the 2h we would expect to see if both battor.trivial_pages and battor.trivial_pages.reference each took an hour to time out.


This doesn't appear to be a Telemetry-wide problem: on the same bot, smoothness.top_25 is failing in 8m14s.

Ned suggested that we add a timestamp before the the "View result at file..." log lines at the end of the trace in order to determine how long each of those uploads are taking. My suspicion, though, is that they aren't the problem, and that instead there's some problem with some atexit handler that the BattOr code registers.