Cypress: 'Aw, Snap' error screen shown when test runs over 250 seconds (approx) intermittant

[sswales]

Current behavior:

Cypress when tests seem to run over 200 seconds you are sometimes presented with a screen showing the following:

'Aw, Snap! Something went wrong while displaying this webpage. Learn More / Reload'

Screenshot:

Desired behavior:

Shouldn't timeout.

Steps to reproduce:

Runs tests around 300s plus using the Chrome browser.

Versions

Version: 2.1.0 to 3.0.2

[sswales]

Just checked and this seems to be even more of an issue in 3.0.2

[sswales]

So just to give a bit more information so this can be looked into further...

The issue seems to be happening less back on 2.1.0, it increased in 3.0.1 and is happening more often in 3.0.2.

Not sure what has been introduced an updated since 3.0.1+ but it's getting worse, it occurs when running over 200s although there isn't a specific time as it varies.

[dylanarmstrong]

@shaunswales have you found any workarounds for this yet? I'm running into this on 3.0.2 as well.

[AlexanderGranhof]

same issue, was able to reach ~2100 seconds at one point, but generally crashes around 200-300 seconds

[Prashant-Kan]

Same issue
sometimes facing Aw snap and sometimes it crashes my application server to run further due to which it throws response timeout error.

[asubota]

+1 same story

[Prashant-Kan]

Hello,

I have tried few solution and it is working for me at the moment but I am still in testing mode with different scenario.

In Cypress.json

{
    "requestTimeout" : 30000,
    "numTestsKeptInMemory": 0,
    "responseTimeout" : 50000,
    "pageLoadTimeout": 100000
}

This is what I have changed.
Anyone who face the same issue try this one.

I got reference from MySameQuestion
and some quick research on default timeout values.

[carloscheddar]

Happening to me as well but only for cypress open. cypress run --browser chrome doesn't have the same issue.

Edit

The issue started happening with --browser chrome as well.

[Prashant-Kan]

Try adding

{
"numTestsKeptInMemory": 0,
}

In your cypress.json. Browser will not crash. It will work.

[patpatx]

Happening to me as well.

As mentioned by @Prashant-Kan, changing "numTestsKeptInMemory": 0, does help prevent the Aw, Snap from appearing. :+1: Thanks for that tip.

Do note that by setting numTestsKeptInMemory to 0, this itself disables the snapshot / limit the capability of Command Log feature.

Just wondering, as I notice Cypress runner saves the snapshot temporarily on the memory, isn't it possible to save it to a file (maybe an option) instead every x MB/test, so as to limit/lessen the possibility of Aw snap memory problem

[duncan-bayne]

We're experiencing this consistently with a long-running test that visits different SaaS systems. It gets towards the end of the test, then crashes Chrome w/ the 'Aw, Snap' message.

• Cypress 3.1.0
• Chrome Version 68.0.3440.106 (Official Build) (64-bit)
• macOS High Sierra 10.13.2

[duncan-bayne]

Some further updates:

1. The workaround proposed by @Prashant-Kan doesn't prevent the crash in our case.
2. The crash happens _every_ time, not intermittently.
3. If we reduce our test case to the minimal "browse to site, enter username and password, log in" then Chrome still crashes. Happens on OSX and Windows.

I think this is a different bug, & will raise as a new issue.

[Prashant-Kan]

Hi, duncan-bayne:

I got reference from MySameQuestion
and some quick research on default timeout values.

Check the explanation in the above-mentioned link maybe you will get your solution.

[Boczarsky]

Hello,

I have tried few solution and it is working for me at the moment but I am still in testing mode with different scenario.

In Cypress.json

{
    "requestTimeout" : 30000,
    "numTestsKeptInMemory": 0,
    "responseTimeout" : 50000,
    "pageLoadTimeout": 100000
}

This is what I have changed.
Anyone who face the same issue try this one.

I got reference from MySameQuestion
and some quick research on default timeout values.

It isn't work for me. Browser still crashes during long tests.

[Prashant-Kan]

@Boczarsky : Correct, Even it fails for me too (now) earlier it was getting passed. But, When my number of steps for the particular testcases increases which eventually increases the Memory, which results in browser crash.

if, Anyone else faces this issue and has the solution please do guide us.

[B3Kay]

This is a big issue at our department where we are doing big end to end testing as we can't do tests taking longer then 250s...

[jennifer-shehane]

Unfortunately we'll have to close this issue if no reproducible example is provided. Can anyone provide a way to reproduce this?

[azollai]

@jennifer-shehane the problem is still appearing in version 3.1.5.
Reproduce it by running a spec file for more than 5 minutes. You can use a simple demo app and put a for loop around it.

[jennifer-shehane]

@azollai I've been unable to reproduce this using your suggestion. My example ran for 569 seconds.

We will need the issue narrowed down more - to specifically what to run to reproduce it.

My test code:

let times = 1000

for (let i = 0; i < times; i++) {
  it('.focus() - focus on a DOM element', () => {
    cy.visit('https://example.cypress.io/commands/actions')
    cy.get('.action-focus').focus()
      .should('have.class', 'focus')
      .prev().should('have.attr', 'style', 'color: orange;')
  })
}

Edited by @jennifer-shehane - Added correct screenshot.

[Saibamen]

@jennifer-shehane: This is Cypress 3.1.5 or unreleased Cypress 4? What is Attempt 1 and Attempt 2 buttons (labels?)?

[EduMotaControliD]

@jennifer-shehane: I have the same problem, I'm running only a inserts of users on a form, it work fine whether I set only litle numbers of users but if I increase that number like 30 or more the browser break. The browser also break when I try to run a bunch of tests, like 6 or more tests, which make others things. I'm running cypress in windows with git bash.

My cypress.json

{
"animationDistanceThreshold": 5,
"baseUrl": "http://localhost:30445",
"blacklistHosts": null,
"chromeWebSecurity": true,
"defaultCommandTimeout": 4000,
"env": {},
"execTimeout": 60000,
"fileServerFolder": "",
"fixturesFolder": "cypress/fixtures",
"hosts": null,
"integrationFolder": "cypress/integration",
"modifyObstructiveCode": true,
"numTestsKeptInMemory": 0,
"pageLoadTimeout": 100000,
"pluginsFile": "cypress/plugins",
"port": null,
"reporter": "spec",
"reporterOptions": null,
"requestTimeout": 30000,
"responseTimeout": 50000,
"screenshotsFolder": "cypress/screenshots",
"supportFile": "cypress/support",
"taskTimeout": 60000,
"testFiles": "**/*.*",
"trashAssetsBeforeRuns": true,
"userAgent": null,
"video": true,
"videoCompression": 32,
"videoUploadOnPasses": true,
"videosFolder": "cypress/videos",
"viewportHeight": 660,
"viewportWidth": 1000,
"waitForAnimations": true,
"watchForFileChanges": true
}

Version output

$ npx cypress version                                                                                                                                                                                           Cypress package version: 3.1.5                                                                                                                                                                                  Cypress binary version: 3.1.5

My set test

it('Login', function ()
    {
        cy.visit('http://localhost:30445/#/login')
        cy.get('#usr').type('My_username')
        cy.get('#pwd').type('My_password')
        cy.get('#confirm').click()
    })

it('Set Users', function ()
    {
        cy.get('#listuser').click()

       for(var i =0; i < 300; i++)
       {
        cy.get('#addUser').click()
        cy.get('#name').type(`User Test ${i + 1}`)
        cy.get('#btnConfirm').click()
        }
})

[jennifer-shehane]

@Saibamen Whoops, this is the wrong screenshot. 😅 This is some work we are doing getting ready for test retries. https://github.com/cypress-io/cypress/issues/1313

[jennifer-shehane]

@EduMotaControliD Is there any way to provide some tests that break that we can run locally?

[Phillipe-Bojorquez]

This happens to me if I am running tests through the GUI and select run all specs. I have 10 specs each one taking 1-3 minutes to run a piece. I get 3/4ths done and get oh snap errors. For me, it doesn't matter how long an individual test is running but a group of specs running over a certain time limit crashes my app. I am uncertain how to share my tests since they concern private things my company would not like me to share. Is there a way to spy on the error message for the GUI test runner that could help debug it?

my spec files have one describe block with a before each block and many it blocks underneath it. Our site does polling so during the tests there may be graphql queries being fired while i interact with the site.

edit: the browser crashes after 5 minutes but is unresponsive to scrolling the left panel at around 3.5 minutes.

[carloscheddar]

I found that having the dev tools open allows chrome to catch the out-of-memory error which causes the browser to pause(debugger state) instead of showing aw snap. If you wait a bit for memory to be available then you can click on the play button and the tests will continue. It's not ideal but at least I can finish testing the file.

[juristr]

Suffering the same issue. Apparently the "numTestsKeptInMemory": 0, solves it for me (at least for now)

[sswales]

Sorry I didn't realise this was still open, yes that is what I needed to implement.

The reason being within windows the application is a 32-bit application, with the tests kept in memory this meant that everything within the DOM for each action was stored. This eventually went over the memory limit for a 32-bit application.

[scharf]

How to reproduce the problem

To reproduce it, duplicate your tests many times and then run the suite. The more complex the pages are the less tests you need.

The problem is: chrome runs out of memory (for the snapshots)

The problem is clearly that chrome runs out of memory. What you will see is: the memory goes up to about 2.5Gb (on my mac) and then just before it fails, the tests run slower and slower (this is typical for running out of memory: the garbage collector takes more and more time) until you see the Aw, Snap!

Side note: I wonder why only few people stumble over this problem. We have only 80 tests and that covers about 10% of our app (it fails at test 79). Either our pages are overly complicated or other teams don't run too many tests. This limitation is a real problem for us, because we cannot expand the number of tests.

Why "numTestsKeptInMemory": 0,` is not a good solution

If I add "numTestsKeptInMemory": 0, to cypress.json, it solves the problem but then I cannot dive into a failed test.

Proposals

Quick solutions

• If I add something "numTestsKeptInMemory": 10, it keeps the last 10 tests. I would be much better to keep the last 10 failed tests. I am not interested in history of the last 10 successful tests....

• Allow to run only some directories. At he moment you can either run a single test or all tests but I see no way to run the tests in a subdirectory

Real solution

• If the app detects that the snapshot take too much memory, drop successful snapshots and add an indicator that the snapshot has been dropped.
• The problem with "numTestsKeptInMemory": 10, (even if it keeps all failed snapshots) is that it is a global configuration. I think the user should be able to change it when a test is run and it should fall back to cleaning up memory automatically.

[CoryDanielson]

@scharf the memory leak and performance issues that you're experiencing are likely fixed with #4068 which is pending a release. The gradual slow down was caused by the increasing memory pressure, and duplicating the contents of external stylesheets to strings (turns out this is an expensive operation). Both of those issues should be fixed. There may still be some performance hit from large embedded stylesheets from <style>tags, though.

[scharf]

@CoryDanielson is there a way to try the pending release (a kind of pre-release)?

[bahmutov]

@scharf there is a way to install pre-release version (when a commit has been merged into develop branch), it is complex though, see https://docs.cypress.io/guides/getting-started/installing-cypress.html#Install-pre-release-version

[scharf]

@CoryDanielson I installed the newest version (https://github.com/cypress-io/cypress-test-example-repos/commit/842608ef90bf4fdf49e36e035c0fccc618a5d836) and it was running 360 tests without problem (before it was failing after 80 tests or so).

I can confirm that it is now much more scalable....

[Domino987]

When can we expect that fix to be in the stable version?

[CoryDanielson]

It was released in 3.3.2

[Domino987]

I see because I still have that problem. I will look more into it. Thanks.

[chaoyangnz]

in my case, I installed a plugin cypress-log-to-output which causes the crashing. So disable your plugins as much as possible. Then isolate the issue.
Sometimes, a plugin is not well tested and add the unpredictable possibilities

[flotwig]

@chaoyangnz can you open an issue on the cypress-log-to-output repo detailing the crash it caused? https://github.com/flotwig/cypress-log-to-output I would like to fix that if possible, wasn't aware of it til just now.

FYI - make sure you're on version 1.0.7 of the plugin if you're using Cypress >= 3.5.0, there was a breaking change.

[chaoyangnz]

@flotwig thanks for your fast response. Actually I am not quite sure that is caused by the plugin. But I tried a lot of options, the final rescue is when I disabled the plugin, then everything is working.

I will isolate the issue, and add more details in your repo. thanks

[jnis77diver]

So, I experienced the "Aw Snap" issue when I added the following to my module.exports in plugins/index.js and tried to run cypress with npx cypress open. It would cause Chrome to crash immediately with the "Aw Snap" message.

  on("before:browser:launch", (browser, launchOptions) => {
    if (browser.family === "chromium") {
      launchOptions.args.push("--enable-logging", "--v=1");
      return launchOptions;
    }
  });
};

Removing it made Cypress open normally again.

[dudziakm]

for me, a good solution was to turn off video recording and compressing ("video": false, in cypress.json).
Of course, this is not a perfect solution :(

[DRiewaldt]

Just in case someone else comes across this issue, a quick tip on what it turned out to be for me. Cypress is running so fast, and our site pushes the limits on memory, it turned out Cypress was out running our garbage collection. This meant we were hitting 4,000,000 K during the test.

I've split the test and it's working now. If you are having this issue, with cypress open start your spec and hit SHIFT + ESC to see the memory of the tab. If your garbage collection can't keep up, you'll be able to see it here before the browser crashes. At which point, just comment some code out to see what will bring you below the 4GB limit.

I also noticed garbage collection doesn't continue after the test has been run once, so if you are iterating on your code and hitting save, you might have to close the browser every time then run the test again. (I'm not sure if there is a way to clear this memory in between runs, anyone know??)

Example: Test runs, it takes 2,400,000 K in memory by the end of the test. If you leave the test and the monitor open, you'll note the memory never goes down once the test is done running but it might go up. If you run the test a second time, you'll see the memory start going up again from 2,400,000 K and hit the 4GB limit before the test fails. This can cause it too look like it's failing at random points, when it's really just because the test was run a second time it's failing as soon as it hits that 4GB cap.

[kristiehowboutdat]

After updating to 5.2.0 from 4.5.0, we are experiencing this issue consistently. Running a single test triggers Aw, snap in Chrome 83. I can run more tests in Firefox 77 before it hits the Aw, snap. We did not hit this in 4.5.0

Plugins: cypress/webpack-preprocessor

Cypress.json

 "numTestsKeptInMemory": 0,
  "video": false,