Cypress: WSL | Electron 5.0 is producing gpu_data_manager_impl_private display compositor crashing

Created on 29 Oct 2019  路  11Comments  路  Source: cypress-io/cypress

Current behavior:

WSL | Electron 5.0 is producing gpu_data_manager_impl_private display compositor crashing. Not able to do a cypress run or open due to this blocking issue. This was never a problem till I just upgraded to Cypress 3.5

Desired behavior:

Works okay and normal like how it did before the upgrade to 3.4

Steps to reproduce: (app code and test code)

Setup: WSL (Ubuntu 18.04, Win10, Cypress 3.4)

  1. Upgrade to Cypress 3.5
  2. After upgrade run the same working command that worked for me before: DEBUG=cypress* ./node_modules/.bin/cypress openconfigFile=dev
  3. I get the following error
    2019-10-29_1530_001

I'm guessing this is related to Electron 5.0 upgrade that is part of 3.5 upgrade

Versions

Setup: WSL (Ubuntu 18.04, Win10, Cypress 3.4)

linux

Most helpful comment

Looks like some users have fixed it by passing a flag to Electron: https://github.com/GoogleChrome/puppeteer/issues/3774#issuecomment-480210268

@adomyaty55foundry You can try patching your cypress to see if this fixes it. Open ./node_modules/cypress/lib/exec/spawn.js, and right above this line:

const child = cp.spawn(executable, electronArgs, stdioOptions)

Add this line:

electronArgs.push('--disable-features=VizDisplayCompositor')

All 11 comments

Looks like some users have fixed it by passing a flag to Electron: https://github.com/GoogleChrome/puppeteer/issues/3774#issuecomment-480210268

@adomyaty55foundry You can try patching your cypress to see if this fixes it. Open ./node_modules/cypress/lib/exec/spawn.js, and right above this line:

const child = cp.spawn(executable, electronArgs, stdioOptions)

Add this line:

electronArgs.push('--disable-features=VizDisplayCompositor')

@flotwig Awesome it did progress but interestingly the const child is var child in my code... not sure why we have different way of calling this variable for Cypress. In any case I added the line here:

electronArgs.push("--disable-features=VizDisplayCompositor")
above
var child = cp.spawn(executable, electronArgs, stdioOptions)

I noticed a new error
2019-10-29_1608

but it didnt stop it continued past that error and then Cypress pop'd but now getting this:

2019-10-29_1609

@flotwig Reinstalled all my browsers still no budge. Atleast we are closer

Here's the current issue now after putting that patch you mentioned manually:

Clicking refresh reproduces/recreates the issue
2019-10-29_1629

@flotwig I got it to work... not sure what made it work but the only thing I did is I ran 'sudo chown -R $USER ' on the /test folder that houses Cypress and it ran fine.

Is this patch going to be merged in in a future patch assuming in 5.0.1 or so? I hate for me to upgrade in the future only to break again and me applying the same suggested patch again manually

@flotwig What actions need to be taken for Cypress here?

New little info: Updated to 3.6 same situation, I had to manually patch my WSL as mentioned above by @flotwig which made it work after :)

I think we should look into giving this as passable flag from CLI maybe to Force OFF the GPU HW accelerator. I can tell you that the trend of Windows users using WSL to basically run a Linux Dev env. is growing sizable amount. WSL possiblly can't handle the GPU acceleration maybe WSL 2 can but that's still ways off till release

@flotwig @jennifer-shehane Will this get patched? I updated to 3.6.1 and still have to manually patch this up with electronArgs.push("--disable-features=VizDisplayCompositor") ? It seems like more harm is done when we force hardware acceleration especially for WSL users

@adomyaty55foundry I'm not sure we want to enable this feature for ALL users, since it only seems to affect WSL. I think we could add an optional environment variable, like CYPRESS_EXTRA_ELECTRON_ARGS, that could be used to work around this (and other) issues.

CYPRESS_EXTRA_ELECTRON_ARGS="--disable-features=VizDisplayCompositor" would be the workaround, if we added that.

This is not currently prioritized as we don't know of too many people using WSL, but you are welcome to open a pull request with the patch and we will review it and get it in as soon as possible.

@flotwig I'm happy to say WSL2 works PERFECTLY with hardware accel. Go microsoft! I took the risk and updated my system to use WSL2 instead

This issue is solved by using WSL2 and by the way it is fast and amazingly less buggy.

@jennifer-shehane I would close this issue but also make sure this info in this ticket is something you guys can be aware or even better document in cypress docs that Cypress works with WSL2 due to hardware limitations with WSL1

Closing - see this issue for WSL1 issue #5918

Was this page helpful?
0 / 5 - 0 ratings