Open DGuentherTV opened 1 year ago
@DGuentherTV
Which CI are you using?
I have seen SIGTRAP produced on cypress/included:latest
started from Docker cli docker run
with --user 1001
. This works correctly in GitHub Actions, but for instance in WSL2 it fails with SIGTRAP.
That may not be related to your issue, however the error messages are similar to yours. It is also strange that you have apparently random problems.
We are using Jenkins as CI system
@DGuentherTV
We are using Jenkins as CI system
Thanks for filling in that information gap!
Cypress 13.2.0 was released yesterday, together with new Docker images. This includes some updates which have improved gpu handling.
You might like to try this new version to see if it improves your outcome.
Hey, sorry for the long silence 😅
Ihave just tried the latest version (13.3.3) of cypress with the latest docker image (node-20.9.0-chrome-118.0.5993.88-1-ff-118.0.2-edge-118.0.2088.46-1)
And it looks like we now moved from SIGTRAP to SIGSEGV (yay, progress 😄)
Thread 1 "Cypress" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
#0 0x0000000000000000 in ?? ()
#1 0x000055b59081fbc2 in node::BaseObjectPtrImpl<node::BaseObject, false>::~BaseObjectPtrImpl (this=0x5b400d78c88) at ../../third_party/electron_node/src/base_object-inl.h:175
#2 std::Cr::pair<node::FastStringKey const, node::BaseObjectPtrImpl<node::BaseObject, false> >::~pair (this=0x5b400d78c70) at ../../buildtools/third_party/libc++/trunk/include/__utility/pair.h:62
#3 std::Cr::__destroy_at<std::Cr::pair<node::FastStringKey const, node::BaseObjectPtrImpl<node::BaseObject, false> >, 0> (__loc=0x5b400d78c70) at ../../buildtools/third_party/libc++/trunk/include/__memory/construct_at.h:66
#4 std::Cr::destroy_at<std::Cr::pair<node::FastStringKey const, node::BaseObjectPtrImpl<node::BaseObject, false> >, 0> (__loc=0x5b400d78c70) at ../../buildtools/third_party/libc++/trunk/include/__memory/construct_at.h:101
#5 std::Cr::allocator_traits<std::Cr::allocator<std::Cr::__hash_node<std::Cr::__hash_value_type<node::FastStringKey, node::BaseObjectPtrImpl<node::BaseObject, false> >, void*> > >::destroy<std::Cr::pair<node::FastStringKey const, node::BaseObjectPtrImpl<node::BaseObject, false> >, void, void> (__p=0x5b400d78c70) at ../../buildtools/third_party/libc++/trunk/include/__memory/allocator_traits.h:323
#6 std::Cr::__hash_table<std::Cr::__hash_value_type<node::FastStringKey, node::BaseObjectPtrImpl<node::BaseObject, false> >, std::Cr::__unordered_map_hasher<node::FastStringKey, std::Cr::__hash_value_type<node::FastStringKey, node::BaseObjectPtrImpl<node::BaseObject, false> >, node::FastStringKey::Hash, std::Cr::equal_to<node::FastStringKey>, true>, std::Cr::__unordered_map_equal<node::FastStringKey, std::Cr::__hash_value_type<node::FastStringKey, node::BaseObjectPtrImpl<node::BaseObject, false> >, std::Cr::equal_to<node::FastStringKey>, node::FastStringKey::Hash, true>, std::Cr::allocator<std::Cr::__hash_value_type<node::FastStringKey, node::BaseObjectPtrImpl<node::BaseObject, false> > > >::__deallocate_node (this=0x5b4002d2da8, __np=0x5b400d78c60) at ../../buildtools/third_party/libc++/trunk/include/__hash_table:1549
#7 std::Cr::__hash_table<std::Cr::__hash_value_type<node::FastStringKey, node::BaseObjectPtrImpl<node::BaseObject, false> >, std::Cr::__unordered_map_hasher<node::FastStringKey, std::Cr::__hash_value_type<node::FastStringKey, node::BaseObjectPtrImpl<node::BaseObject, false> >, node::FastStringKey::Hash, std::Cr::equal_to<node::FastStringKey>, true>, std::Cr::__unordered_map_equal<node::FastStringKey, std::Cr::__hash_value_type<node::FastStringKey, node::BaseObjectPtrImpl<node::BaseObject, false> >, std::Cr::equal_to<node::FastStringKey>, node::FastStringKey::Hash, true>, std::Cr::allocator<std::Cr::__hash_value_type<node::FastStringKey, node::BaseObjectPtrImpl<node::BaseObject, false> > > >::clear (this=0x5b4002d2da8) at ../../buildtools/third_party/libc++/trunk/include/__hash_table:1777
#8 std::Cr::unordered_map<node::FastStringKey, node::BaseObjectPtrImpl<node::BaseObject, false>, node::FastStringKey::Hash, std::Cr::equal_to<node::FastStringKey>, std::Cr::allocator<std::Cr::pair<node::FastStringKey const, node::BaseObjectPtrImpl<node::BaseObject, false> > > >::clear (this=0x5b4002d2da8) at ../../buildtools/third_party/libc++/trunk/include/unordered_map:1365
#9 node::Environment::RunCleanup (this=0x5b4002d2400) at ../../third_party/electron_node/src/env.cc:1013
#10 0x000055b5907de8c9 in node::FreeEnvironment (env=0x5b4002d2400) at ../../third_party/electron_node/src/api/environment.cc:445
#11 0x000055b58975dc75 in electron::NodeEnvironment::~NodeEnvironment (this=<optimized out>) at ../../electron/shell/browser/javascript_environment.cc:346
#12 0x000055b5897475a5 in std::Cr::default_delete<electron::NodeEnvironment>::operator() (this=<optimized out>, __ptr=0x5b4003895b0) at ../../buildtools/third_party/libc++/trunk/include/__memory/unique_ptr.h:65
#13 std::Cr::unique_ptr<electron::NodeEnvironment, std::Cr::default_delete<electron::NodeEnvironment> >::reset (this=0x5b40024d9e0, __p=0x0) at ../../buildtools/third_party/libc++/trunk/include/__memory/unique_ptr.h:297
#14 electron::ElectronBrowserMainParts::PostMainMessageLoopRun (this=0x5b40024d980) at ../../electron/shell/browser/electron_browser_main_parts.cc:607
#15 0x000055b58bb58355 in content::BrowserMainLoop::ShutdownThreadsAndCleanUp (this=0x5b400290c80) at ../../content/browser/browser_main_loop.cc:1131
#16 0x000055b58bb59fae in content::BrowserMainRunnerImpl::Shutdown (this=0x5b400305320) at ../../content/browser/browser_main_runner_impl.cc:176
#17 0x000055b58bb557c8 in content::BrowserMain (parameters=...) at ../../content/browser/browser_main.cc:43
#18 0x000055b589930694 in content::RunBrowserProcessMain (main_function_params=..., delegate=0x7ffd08ac2910) at ../../content/app/content_main_runner_impl.cc:710
#19 0x000055b589931f1e in content::ContentMainRunnerImpl::RunBrowser (this=0x5b400248000, main_params=..., start_minimal_browser=<optimized out>) at ../../content/app/content_main_runner_impl.cc:1280
#20 0x000055b589931d38 in content::ContentMainRunnerImpl::Run (this=0x5b400248000) at ../../content/app/content_main_runner_impl.cc:1134
#21 0x000055b58992f675 in content::RunContentProcess (params=..., content_main_runner=0x5b400248000) at ../../content/app/content_main.cc:330
#22 0x000055b58992f765 in content::ContentMain (params=...) at ../../content/app/content_main.cc:347
#23 0x000055b58966ceed in main (argc=<optimized out>, argv=0x7ffd08ac2ae8) at ../../electron/shell/app/electron_main_linux.cc:40
@DGuentherTV
Did I understand you correctly that you are running the Cypress Docker container inside a Debian container on Ubuntu or did I misunderstand and the Cypress Docker container runs directly under Ubuntu?
Edit: According to /etc/debian_version
the Cypress Docker container cypress/browsers:node-20.9.0-chrome-118.0.5993.88-1-ff-118.0.2-edge-118.0.2088.46-1
is built on Debian 11.8
.
The Cypress Docker container cypress/browsers:node-18.16.0-chrome-114.0.5735.133-1-ff-114.0.2-edge-114.0.1823.51-1
is built on Debian 11.7
.
I'm on @DGuentherTV's team.
@MikeMcC399 Correct, the image is built on Debian and runs either on baremetal Ubuntu 22.04 machines (where it's a little better), or on Ubuntu 22.04 VMs (where it's real bad). The difference between running on baremetal or VMs is mostly an interesting curiosity, the problem appears on either.
This is very frustrating for our entire organization because we run Cypress as part of every CI build, and devs need to wait 16 minutes for all Cypress tests to pass successfully only for it to exit with
✔ All specs passed! 16:06 225 192 - 33 -
The Test Runner unexpectedly exited via a exit event with signal SIGSEGV
We also don't know what our best bet would be for circumventing the issue, as we haven't found anything that even remotely improves the situation. Should we try a different Docker image, maybe one not built on Debian and/or roll one ourselves? Currently, debates are starting about switching to Playwright just to not have this problem :/
@JosXa
FYI: We have now created a docker image based on node:18.18.2-bookworm-slim
where the crash seems to be gone.
Might be the Debian update, might be some setting/env that we did not set in comparison to the official cypress images.
@DGuentherTV
FYI: We have now created a docker image based on
node:18.18.2-bookworm-slim
where the crash seems to be gone.Might be the Debian update, might be some setting/env that we did not set in comparison to the official cypress images.
Great news!
I'd suggest that you close this issue now if you have a solution.
12
(bookworm
), which might also be relevant for reference.
Current behavior
When running in our CI environment, Cypress (verify, info, run) randomly crashes with this error message:
The weird thing is, that this happens seemingly random and may work and fail in the same container f.ex. verify works, but then run crashes even running verify 2 times could work once or twice or not at all
Even weirder: we didn't change anything in the docker image nor did we update cypress, yet the problem got somehow worse
Running the cypress binary directly with an attached gdb results in the following backtrace when this crash happens:
We have tried a lot so far:
--disable-gpu
--ipc=host
,-e HOME=/root
cypress/browsers:node-18.16.0-chrome-114.0.5735.133-1-ff-114.0.2-edge-114.0.1823.51-1
Maybe someone here has an idea or knows where we can find help
Desired behavior
Cypress should verify and run reliably
Test code to reproduce
N/A
Cypress Version
12.17.3
Node version
18.17.0
Operating System
Host: Ubuntu 22.04, Container: Debian - 11.6
Debug Logs
No response
Other
No response