If "We detected that the Chromium Renderer process just crashed." still output report

[tomardern]

Current behavior:

If cypress crashes due to "We detected that the Chromium Renderer process just crashed.", it does not produce a mocha report:

Checkout Test
 ✓ Can load the site (5958ms)
We detected that the Chromium Renderer process just crashed.
 This is the equivalent to seeing the 'sad face' when Chrome dies.
 This can happen for a number of different reasons:
 - You wrote an endless loop and you must fix your own code
- There is a memory leak in Cypress (unlikely but possible)
- You are running Docker (there is an easy fix for this: see link below)
- You are running lots of tests on a memory intense application
- You are running in a memory starved VM environment
- There are problems with your GPU / GPU drivers
- There are browser bugs in Chromium
 You can learn more including how to fix Docker here:
 https://on.cypress.io/renderer-process-crashed
 (Results)
 ┌──────────────────────────────────────┐
 │ Tests: 0 │
 │ Passing: 0 │
 │ Failing: 1 │
 │ Pending: 0 │
 │ Skipped: 0 │
 │ Screenshots: 0 │
 │ Video: true │
 │ Duration: 0 seconds │
 │ Spec Ran: checkout/basic.spec.js │
 └──────────────────────────────────────┘
 (Video)
 - Started processing: Compressing to 32 CRF
 - Finished processing: frontend/tmp/cypress/videos/checkout/basic.spec.js.mp4 (6 seconds)

^^ (Note no mocha report is generted)

Desired behavior:

The mocha report is also outputted/saved, this is so that (for us) the mocha-awesome report can be generated and uploaded via our CI.

Steps to reproduce: (app code and test code)

Make the chrome renderer crash.

Versions

Latest cypress, we are running on CI/CD (AWS CodeBuild) - all other tests are fine, it's this one that randomly crashes. (Thats another issue).

If this is an issue with the reporter - please let me know and I'll raise an issue there.

Thanks :)

[Nomeasmo]

We also have this issue in a flaky manner, so cannot provide a working example. But it shows the tests run with version 3.2.0 but are failing with 3.3.2 and 3.4.

Maybe this helps. (Internally we think it might be the electron version)

[pauldcomanici]

I started to encounter this error with version 3.6.0 and now tested with 3.6.1 and still happens.

With 3.4.1 version I never encountered it.

[mattrlong]

Also started experiencing this while attempting to upgrade from 3.4.0 -> 3.6.1

[jasondeng]

Started encountering this after upgrading from 3.4.1 -> 3.7.0

[mattrlong]

@jasondeng @darkyndy are you using kubernetes by any chance?

[pauldcomanici]

@mattrlong yes

[mattrlong]

@mattrlong yes

Same, and also experiencing this issue. How many parallel runners are you using? Are you using resource limits on your Pods?

[mattrlong]

Have you tried to prevent this issue in the past? ipc=host solution processed I've been advised against in my k8 pod definition. I'm currently using shared /dev/shm volume mounts. This prevents the issue on 3.4.1 for me, but crashes on every Jenkins build for me on 3.6.1 & 3.7.0.

Wondering if this is something you're also experiencing?

[pauldcomanici]

I do not have access to k8s setup as this is maintained by the Ops team and as I'm the owner of the single project that uses Cypress they will not do any changes specific to my project.

If it is a way to configure cypress or to run some bash script (I have sudo) on the docker image that could be a solution for me.

Later edit:

How many parallel runners are you using? Are you using resource limits on your Pods?

Yes every pod is limited, need to check with Ops what is in place. I'm using 3 parallel runners by using npm-run-all package, part from scripts:

    "test-e2e-dev-group-full": "npm-run-all test-e2e-verify --aggregate-output -n -l -p test-e2e-dev-partial-group-*",
    "test-e2e-dev-partial-group-1": "npm run test-e2e-run -- --env=dev --test=full --subTest=g1",
    "test-e2e-dev-partial-group-2": "npm run test-e2e-run -- --env=dev --test=full --subTest=g2",
    "test-e2e-dev-partial-group-3": "npm run test-e2e-run -- --env=dev --test=full --subTest=g3",
    "test-e2e-run": "node scripts/e2e.js",
    "test-e2e-pipeline": "start-server-and-test start http-get://localhost:3000 test-e2e-dev-group-full",
    "test-e2e-verify": "cypress verify",

and everything start from sh command:

unset DISPLAY && npm run test-e2e-pipeline

Note: I tried with 4 and the docker instance crashed :) this is why I have only 3 groups.

[davidzambrana]

We also started seen this after upgrading to 3.7.0

It only breaks in our CI where we use k8s

[nantoniazzi]

We have tried an upgrade to 3.7.0 and we have the same issue (tests are run from docker, in gitlab-ci)

[pshynin]

we have circle-ci and also jenkins-kuberneties.. crushing in both.
kuberneties kills cypress pods due to spikes in CPU usage, but circle-ci crushes with exact same error message...
spent few days figuring out, gave up for now and downgraded back to 3.4.1

[domachine]

we have circle-ci and also jenkins-kuberneties.. crushing in both.
kuberneties kills cypress pods due to spikes in CPU usage, but circle-ci crushes with exact same error message...
spent few days figuring out, gave up for now and downgraded back to 3.4.1

Same here. In my case I use cypress to test a ReST API. I do not even load a website. Just sending requests using cy.request(). It's really strange. Each time a core dump is created. It happens only when being run on the CI server. Locally everything works like a charm.

[ameem91]

I'm also seeing this same issue. I stub all requests using mock data, so my tests don't even take that long to run. I'm on 3.8.2.

[dialex]

I'm having the same issue, with the latest Cypress (4.0.1) on self-hosted GitLab.
If I run them locally, they pass without issues (at least so far).

[ghost]

Also running into this same issue. We were looking to upgrade to Cypress 4.0.2, but cannot. Works fine on 3.4.1

[michaelhayman]

Running into a similar issue on 4.0.2. Wasn't seeing the issue on earlier versions.

[JoniVR]

We are running into the same issue on Gitlab CI

Technology	Version
Cypress	4.0.2
Electron	Electron 78 (headless)

[JoniVR]

Here's our workaround for Cypress 4.0.2 (we use Gitlab CI):

1. We changed our run command to use chrome instead of electron

"e2e-headless": "ng e2e --headless --browser chrome",

(might be a different command for you because we use angular, just append --browser chrome)

2. Then inside the cypress/plugins/index.js file we added the following to enable the --disable-dev-shm-usage chrome flag:

module.exports = (on, config) => {
  // `on` is used to hook into various events Cypress emits
  // `config` is the resolved Cypress config

  on('before:browser:launch', (browser = {}, launchOptions) => {
    // `args` is an array of all the arguments that will
    // be passed to browsers when it launches

    if (browser.family === 'chromium' && browser.name !== 'electron') {
      // see: https://github.com/cypress-io/cypress/issues/3633
      launchOptions.args.push('--disable-dev-shm-usage');

      // whatever you return here becomes the launchOptions
      return launchOptions;
    }
  });
};

3. In our ci conflig, we changed the image to:

image: cypress/browsers:node12.13.0-chrome80-ff73

So we could use chrome 80 (not sure if chrome 80 is necessary but doesn't hurt)

After that our CI passed without issues, hope this helps any other poor souls running into this :)

[leads]

@JoniVR re point 3, you've change the docker image. What do you install cypress with? As the image you use doesn't include the runner itself. (Unless I'm mistaken.)
Thanks

[JoniVR]

@leads We run the npm ci command first, which installs cypress through npm if not available (it's part of our package.json). We've also cached the cypress cache folder so it doesn't have to download it every time.

Although I'm pretty sure you'll be able to find base images that have cypress included with chrome 80+ by now, I just said v80+ because I wasn't sure if that specific argument was supported before v80.

[leads]

Thanks @JoniVR for such a quick response. Ours is all done via a docker file which uses cypress/included:4.0.2 and that is what installs cypress.

I'll have a play with your solution.

[mirobo]

With Cypress 10.7.0 I have observed a similar behaviour. I didn't check whether the output report exists. But when a test fails with "Chromium Renderer process just crashed" it will not be reported to sorry-cypress (and probably also not Cypress dashboard). Luckily the build job in GitLab will fail but the test itself in sorry-cypress will remain in the state "Running" and will turn into "timed out" or something else later on.

Also these test failures are not retried (see #349)

Anybody who is using sorry-cypress with cypress-cloud could probably also profit from this feature request currents-dev/cypress-cloud#121 but ideally it would be solved in Cypress itself.

[nagash77]

This issue is for a very old version of Cypress. I am going to close it. If anyone has a reproducible example on a later version of Cypress please comment back here or open a new issue and we will be happy to investigate.