We got an error when setting up the timeline log, it happens on the first run when we fill the WebPageReplay cache, and then all the runs get wrong amount of requests. https://github.com/sitespeedio/browsertime/issues/435
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Peter | T182510 Measure time spent in scripting/painting/rendering for Chrome [proxy] | |||
| Resolved | Peter | T186101 Error getting the timeline log |
Event Timeline
Comment Actions
I'm gonna do one push today that changes the DBUS_SESSION_BUS_ADDRESS (https://github.com/SeleniumHQ/docker-selenium/issues/87) that best case will stop the Chromedriver to hang, but I'm not 100% sure that is actually that that happens (we don't have the log from the Chromedriver turned on at the moment, we could turn that on but it logs soooo much and the error happens so rarely).
Comment Actions
The DBUS_SESSION_BUS_ADDRESS didn't help.
I've spent time on this today and it's something going on in the Chrome/Chromedriver world: The error happens when we fetch the minimal trace log (devtools.timeline) and I can reproduce that locally. It happens sometimes. If I instead configure devtools.timeline and disabled-by-default-devtools.timeline it never happens (locally at least) so I will try that now on one of the servers and hope that the metrics will be stable.
Comment Actions
It didn't help: I can get the error locally with disabled-by... config too. I'll create an upstream issue tonight/tomorrow.
Comment Actions
I spent a lot of time last night trying to nail down the problem. It only happens for Chrome/Chromedriver on Linux and could finally do a simple tets case where it is reproducible: https://bugs.chromium.org/p/chromedriver/issues/detail?id=2271
Comment Actions
I've made a change now by emptying the trace log before setting it. When I searched for bugs in Chrome it seems that is the way to do it. So now we run with: --chrome.traceCategories='-*,disabled-by-default-devtools.timeline'