cypress: The Chromium Renderer process just crashed - 'sad face' Error
Hi, I am running m cypress script in headless mode on a remote ubuntu 18.03 machine. The strange thing is that it works fine on my local macbook, but I’m getting an error that the Chromium renderer is crashing when running on the ubuntu server. Here is the output:
We detected that the Chromium Renderer process just crashed.
[1]
[1] This is the equivalent to seeing the 'sad face' when Chrome dies.
[1]
[1] This can happen for a number of different reasons:
[1]
[1] - You wrote an endless loop and you must fix your own code
[1] - There is a memory leak in Cypress (unlikely but possible)
[1] - You are running Docker (there is an easy fix for this: see link below)
[1] - You are running lots of tests on a memory intense application
[1] - You are running in a memory starved VM environment
[1] - There are problems with your GPU / GPU drivers
[1] - There are browser bugs in Chromium
[1]
[1] You can learn more including how to fix Docker here:
[1]
[1] https://on.cypress.io/renderer-process-crashed
[1] TypeError: onError is not a function
[1] at BrowserWindow.onCrashed (/home/ubuntu/.cache/Cypress/4.4.0/Cypress/resources/app/packages/server/lib/modes/run.js:538:7)
[1] at WebContents.<anonymous> (/home/ubuntu/.cache/Cypress/4.4.0/Cypress/resources/app/packages/server/lib/gui/windows.js:181:34)
[1] at WebContents.emit (events.js:215:7)
[1]
[1] TypeError: onError is not a function
[1] at BrowserWindow.onCrashed (/home/ubuntu/.cache/Cypress/4.4.0/Cypress/resources/app/packages/server/lib/modes/run.js:538:7)
[1] at WebContents.<anonymous> (/home/ubuntu/.cache/Cypress/4.4.0/Cypress/resources/app/packages/server/lib/gui/windows.js:181:34)
[1] at WebContents.emit (events.js:215:7)
[1]
[1] The Test Runner unexpectedly exited via a exit event with signal SIGILL
[1]
[1] Please search Cypress documentation for possible solutions:
[1]
[1] https://on.cypress.io
[1]
[1] Check if there is a GitHub issue describing this crash:
[1]
[1] https://github.com/cypress-io/cypress/issues
[1]
[1] Consider opening a new issue.
[1]
[1] ----------
[1]
[1] Platform: linux (Ubuntu Linux - 18.04)
[1] Cypress Version: 4.4.0
Is there any way for me to see why it is crashing? 🤔
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 18 (5 by maintainers)
Commits related to this issue
- build: use chrome for e2e tests There's a known issue with Electron in this version of cypress that leads to a memory leak and therefore a test run crash. Look at this GH issue for more: https://gith... — committed to imgix/vue by luqven 2 years ago
- fix: try to fix cypress with magic I'm trying this because it might have worked for someone on the internets https://github.com/cypress-io/cypress/issues/7204 — committed to apache/superset by mistercrunch 5 months ago
Unfortunately we’ll have to close this issue if there is not enough information to reproduce the problem. This does not mean that your issue is not happening - it just means that we do not have a path to move forward.
There’s a lot of things that could contribute to the browser crashing, including issues from the underlying application under test that don’t have to do with Cypress. Please comment in this issue with a reproducible example so we can assess that this is an issue specific to Cypress.
I had a similar issue to what you’re describing. Running tests in parallel will mostly mitigate the issue, but a big spec file could still cause the process to crash. I was able to address the memory issue by exposing the garbage collector and running it between tests.
See https://github.com/cypress-io/cypress/issues/8525 and https://github.com/cypress-io/cypress/issues/350#issuecomment-688969443
Garbage collection is an expensive operation. Javascript’s automatic garbage collector will try to stay out of your way, and only run when there is downtime in the code. The issue with this is that even very basic Cypress tests are quite intensive programs that do not have much downtime. When one test finishes, another test runs and so on until there are no tests remaining. The garbage collector will sometimes step in to free up memory, but not often enough to prevent out of memory crashes.
When testing a complex page with lots of requests and events, this issue becomes more noticeable. As Electron/Chrome approaches their max MB threshold (2GB by default), the JS runtime does not seem to get more aggressive with garbage collection. In my case, I saw 1.8GB used, and no decrease – the next test to kick off would put it over 2GB and the app would crash.
@JimLynchCodes Did you try the same tests in Chrome headless?
I disabled the shm usage as per the suggestion from @jennifer-shehane here #7200 and even then Electron would crash and the Chromium renderer error would be thrown.
I changed the run command to have
--headless --browser chromeand now the tests are running fine. Can you check if your tests fail on Chrome too?I added the profiling environment variable
DEBUG=cypress:server:util:process_profiler cypress run, but I’m still not really sure what’s causing the issue.My output looks like this image below. It seems that with every print the first like, “Electron”, is taking more and more memory usage. Everything else seems to be pretty stable.
Closing as resolved. Running Cypress does require some resources, so running it on an underpowered machine can cause Chrome to crash, especially when testing pages with lots of requests and DOM interactions.
@CoryDanielson We’ll have to take a look at the window.gc() suggections.
If you’re experiencing a bug similar to this in Cypress, please open a new issue with a fully reproducible example that we can run. There may be a specific edge case with the issue that we need more detail to fix.
I have the same issue while running cypress in headless mode in Gitlab CI. We have only 5 tests
Version 4.4.1 - works fine Version 4.5+ - crashes almost every time
We are using docker image provided by cypress:
cypress/base:12.18.0which should be fine but for some reason it started to fail.For now we stick to version 4.4.1 as it seems to be stable enough. We are considering firefox as it tend to use less memory but we haven’t gave it a shot just yet