SIGSEGV after passing all tests #7048
Comments
|
@bwiklund Is your output also printing Could you run Cypress in debug mode mode and print the entire set of logs here? |
jennifer-shehane
added
the
stage: needs information
|
Hi @jennifer-shehane my colleague reported #7073 which was closed in favour of this - can't speak for @bwiklund but with I can share the whole file if you let me know the best way to do this. Thanks! |
|
@jamesdonoh Yeah, your SIGSEGV doesn't look to be logged after all the tests are run, but in between one spec before starting a new spec. The log of course gives no helpful information :( |
|
@jennifer-shehane is there anything else we can do to help diagnose the cause of this please? The issue we reported above was closed as a dupe of this one, and since migrating to 4.4.0 70-80% of our test runs now crash in this way. |
Still seeing these crashed on 4/5 of our test runs. We upgraded to cypress 4.4.0 to move away from a security vulnerability in an older version and are reluctant to rollback re-introducing that security vuln. Any updates would be appreciated. |
|
Just adding another report that the SIGSEGV is happening, with no useful log at all. |
|
Hi, We have the same issue here, reproduced with a minimal single test: describe('My First Test', () => {
it('Visits the home', () => {
cy.visit('/');
});
});
{}Ran either in (gitlab-)ci with CYPRESS_BASE_URL=http://localhost:3000 npx run cypressExecuted cypress version was The error with DEBUG log activated is similar to what was previously indicated: cypress:cli child event fired { event: 'exit', code: null, signal: 'SIGSEGV' } +13s
The Test Runner unexpectedly exited via a exit event with signal SIGSEGVAlso note that we sometimes got the cypress:cli child event fired { event: 'exit', code: null, signal: 'SIGBUS' } +13s
The Test Runner unexpectedly exited via a exit event with signal SIGBUSI then ran the following command: DEBUG=* CYPRESS_BASE_URL=https://www.google.com npx cypress run10 times out of 10, the result was a success by targeting the Our web app renders much more slowly than the Hope this helps narrow down the problem. Of course we are working on making our app faster (but don't have control over all scripts, and need to be able to run cypress while the app is in Is there a workaround to increase the limit (time / memory), for resource heavy web apps? |
|
Same problem seems to happen for me, in |
|
yeah.... same problem in our CI: |
|
Platform: linux (Debian - 8.10) |
|
Same here using v4.5.0. Our specs pass locally but on Travis-CI fail after 2 minutes of the initial specs passing with: After restarting the Travis build about 3 times it will complete successfully. Cypress 4.3 passes every time no problem. We are using cypress with TypeScript and no plugins. We are using fixtures only with quite a heavy API. cypress.json: {
"supportFile": "cypress/support/index.ts",
"videoUploadOnPasses": false,
"baseUrl": "http://localhost:3030/_",
"env": {
"apiUrl": "http://localhost:3000/api/v2/"
}
}On Travis we're using a VM with 7.5Gb memory, no docker. Travis config: dist: xenial
language: node_js
node_js: 10
addons:
chrome: stable
cache:
yarn: true
directories:
- node_modules
env:
- NODE_OPTIONS="--max_old_space_size=6144" # ensure enough memory for the tests
before_install:
- curl -o- -L https://yarnpkg.com/install.sh | bash
- export PATH=$HOME/.yarn/bin:$PATH
before_script:
- yarn start --silent &
script:
- set -e # Exit immediately if a subsequent command fails
- yarn install --non-interactive --production=false --pure-lockfile
- cypress install && yarn cypress run --config video=false
- kill $(jobs -p) || true |
|
With Cypress 4.6 the tests all complete but the Cypress process locks up logging the final output:
|
|
Still failing with v4.8 |
|
So we did these 3 things and our Travis Cypress runs no longer hang. Not sure which one fixed it but I suspect it's the file watching because it's a very large codebase.
.travis.yml - Added - cypress install && yarn cypress run --config watchForFileChanges=falsecraco.config.js - added this: ...(process.env.CI && {
devServer: {
watchOptions: {
ignored: '/**',
},
},
}), |
|
Hi all... looks like I'm joining the party with this crash: I saved my changes which triggered the test to run again as I still had the test browser open from the previous test. This happened to me twice in a span of 5 minutes :( |
|
Cypress: 5.4.0 Tests are run via API and work perfectly on Cypress 5.3.0 UPDATE |
|
Hi @jennifer-shehane I have encountered the same issue after upgrading from 5.3.0 to the latest 5.4.0 even with all tests passing. I use the docker image |
jennifer-shehane
added
the
topic: SIG errors
|
Commenting here as my post was closed as a duplicate, the same issue is occuring in our CI and local environments to error unexpectedly after all tests have passed successfully. We are using This is screenshot of local run failing with debug, |
|
Also crashes even though all spec is passed in the bitbucket pipeline. I have no problem with a crash, but this crash makes my test run failed even though all passed. At my local also crash like this. |
- More details on the issue go to: cypress-io/cypress#7048
|
SOLUTION: Cypress version 5.6.0 in MacOS, when running through terminal, after all the tests complete, cypress crashes and I am getting the same error: I found the reason. the entry |
|
@rakesh-basavaraju , if you revert back cypress version to 7.6.0, hopefully that issue will resolve |
|
Same issue for me: |
|
Same issue started happening today when test suite starts on first test on github actions: |
|
Same issue for me today: |
cypress-bot
bot
added
stage: backlog
and removed
stage: needs information
|
So I decided to try and do a major upgrade on the docker image that runs cypress and went to: still the exact same issue: |
|
still having the same issue on cypress 10.2.0 and cypress/browsers:node14.19.0-chrome100-ff99-edge image, we have 8gb ram on the ci runners, not sure what caused the issue. |
|
For us on Circle CI the issue os intermittent but in Docker running on Mac we seemed to be able to reproduce every time |
|
I am running into this same issue -> are there any known workarounds? |
|
@cooleiwhistles only |
|
we encountered same issue with cypress version 12.11.0. are there any known workarounds? |
|
Ive managed to get it stable on '12.3.0'. Make sure you lock your package.jsons to exact versions and in docker images install the exact version too. Only upgrade in small steps and validate each version works instead of having auto incrementing versions. |
We changed the version but error still exists. The error became "child event fired { event: 'close', code: null, signal: 'SIGTRAP' } " |
|
@ardasendur, @mattvb91, or anyone else, would you be able to recreate the SIGSEGV fault in a reproduction repository by forking cypress-test-tiny or by other means? We would love to determine the cause of the failure instead of being forced to be on a previous version of Cypress. |
we will try after a while I will inform you. |
|
@ardasendur any luck with being able to provide a reproduction repository? |
|
Right now there doesn't seem to be enough information to reproduce the SIGSEGV fault on our end. We'll have to close this issue until we can reproduce it. This does not mean the issue is not happening - it just means that we do not have a path to move forward. Please comment with a reproducible example concerning the original issue and we can reopen. |
and others
I can't comment on the original ticket because it's locked, but this bug #6458 still exists on 4.4.0 as of this evening
The text was updated successfully, but these errors were encountered: