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

Docker crashes when renderer process eats up too much memory #350

Closed
brian-mann opened this Issue Dec 16, 2016 · 4 comments

Comments

4 participants
@brian-mann
Member

brian-mann commented Dec 16, 2016

Related to #348 and #349.

When running headlessly on very long and memory intense applications we are seeing renderer crashes with Docker.

@brian-mann

This comment has been minimized.

Show comment
Hide comment
@brian-mann

brian-mann Dec 16, 2016

Member

This is actually not indicative of a memory leak inside of Cypress (nor your application). This has to do with the way that browsers work under the hood.

Luckily, we have a found a simple one line fix for this problem - simply add the flag --ipc=host.

This option is documented here.

The Slack app and Atom has also been documented to crash here, here, and here for the exact same reasons.

If you are using docker run

docker run --ipc=host

If you are using docker compose

version: '2'
services:
  foobarbazservice:
    ipc: host ## this line right here

In the future we are working on a more permanent fix such as described in #349 - either to automatically recover from these crashes, or mostly prevent them up from by nuking the renderer process in between spec files.

Member

brian-mann commented Dec 16, 2016

This is actually not indicative of a memory leak inside of Cypress (nor your application). This has to do with the way that browsers work under the hood.

Luckily, we have a found a simple one line fix for this problem - simply add the flag --ipc=host.

This option is documented here.

The Slack app and Atom has also been documented to crash here, here, and here for the exact same reasons.

If you are using docker run

docker run --ipc=host

If you are using docker compose

version: '2'
services:
  foobarbazservice:
    ipc: host ## this line right here

In the future we are working on a more permanent fix such as described in #349 - either to automatically recover from these crashes, or mostly prevent them up from by nuking the renderer process in between spec files.

@jheijkoop

This comment has been minimized.

Show comment
Hide comment
@jheijkoop

jheijkoop Dec 22, 2017

I seem to be getting this problem too, because Chrome is running out of shared memory (/dev/shm). By default docker starts images with a 64M /dev/shm (try running df -h in you instance). To change this you can supply docker with an extra argument: docker run --shm-size 512M my-image. Because we are working with mesos/marathon I had to do this via the "docker": { "parameters": [{"key": "shm-size", "value": "512M"}], ...} (https://mesosphere.github.io/marathon/docs/native-docker.html) in the json configuration when creating the app/instances.

jheijkoop commented Dec 22, 2017

I seem to be getting this problem too, because Chrome is running out of shared memory (/dev/shm). By default docker starts images with a 64M /dev/shm (try running df -h in you instance). To change this you can supply docker with an extra argument: docker run --shm-size 512M my-image. Because we are working with mesos/marathon I had to do this via the "docker": { "parameters": [{"key": "shm-size", "value": "512M"}], ...} (https://mesosphere.github.io/marathon/docs/native-docker.html) in the json configuration when creating the app/instances.

@einomi

This comment has been minimized.

Show comment
Hide comment
@einomi

einomi Mar 23, 2018

I had the same issue with Codeship CI. Just needed to change config in my codeship-services.yml file, according to documentation https://documentation.codeship.com/pro/continuous-integration/browser-testing/#chrome-crashing

einomi commented Mar 23, 2018

I had the same issue with Codeship CI. Just needed to change config in my codeship-services.yml file, according to documentation https://documentation.codeship.com/pro/continuous-integration/browser-testing/#chrome-crashing

@jennifer-shehane

This comment has been minimized.

Show comment
Hide comment
@jennifer-shehane

jennifer-shehane Mar 23, 2018

Member

I wonder if this is related to our other issue with a Codeship CI run failing.#328 Unfortunately, we don't have a pro account, and the codeship-services.yml is only available on pro.

Member

jennifer-shehane commented Mar 23, 2018

I wonder if this is related to our other issue with a Codeship CI run failing.#328 Unfortunately, we don't have a pro account, and the codeship-services.yml is only available on pro.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment