-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chrome crashes when running stacks gatherer sometimes #11124
Comments
As requested: $ chromium-browser --product-version Lighthouse runs shows following environment as |
Hm, something is strange here @dimension85 . Lighthouse was using |
They are from the same environment and consistent across all the environments. |
OK thanks @dimension85 I tried with Lightsail running exactly these steps and I can reproduce a PROTOCOL__TIMEOUT now 👍
Installing |
Verbose logs seem to indicate it's a hanging network request for
|
sounds like your making progress - is there a workaround or specific audit related to this that I can suppress for now? |
Unfortunately, no. The stacks gatherer is run on every run single invocation of Lighthouse without a way to skip it :/
The workaround from my perspective is run Lighthouse in literally any other environment than Lightsail 😆 I couldn't reproduce it anywhere but there. |
Hmm, I think your logic is the wrong way around as you are suggesting I move from a stable environment that has a repeatable and fixable error on it to one that has a random and unable to diagnose error on it? Perhaps everyone should move to Lightsail so the problem could be diagnosed? The fact you cannot replicate it does not suggest it does not happen as thread 6512 shows /lighthouse-core/gather/driver.js:352:21 has occurred for others as well - are these the same or similar issues? |
The incidence rate in other CLI environments is very low. There are many, many services that run Lighthouse in other cloud environments that don't run into this. In our own infrastructure in GCP this error occurs <1% of the time where a retry is more than reasonable. Generally, yes, I would consider moving from an environment that fails 100% of the time to one that fails <1% to be a decent temporary workaround.
That is the location for the umbrella error of Chrome took too long to respond. We are well aware that this error occurs. The problem is that it can occur for 1000 different reasons. We are grateful you have been the first person to ever find a specific URL in a specific environment where it always occurs due to a very specific reason and we will take steps to fix that specific source. Most of the time though this happens for sporadic, transient, and unrelated-to-Lighthouse reasons that aren't going away and PROTOCOL__TIMEOUT will continue to happen. |
I have also seen other random PROTOCOL__TIMEOUT events which I have found a retry resolves, so was surprised when this occurred. I appreciate the effort and priority you have applied to this and look forward to the fix when it becomes available. |
Huzzah, we've found an even more reproducible example of this exact same issue, but it occurs in every environment! 🎉 https://www.tiffany.com/ gets stuck in the stacks gatherer in PROTOCOL_TIMEOUT every time, in every environment I tested. This will make a fix much easier to test 👍 |
Filed from GoogleChrome/lighthouse-ci#381 (comment)
Provide the steps to reproduce
What is the current behavior? Chrome appears to crash and then Lighthouse exits with the dreaded protocol took too long error.
What is the expected behavior? Lighthouse returns results.
Environment Information
Related issues
ref #6512
I have been unable to reproduce this error so far, but Chrome crashing in the middle probably should result in a more specific error message with Chrome log output rather than the dreaded protocol message.
The text was updated successfully, but these errors were encountered: