← Back to microsoft/playwright
microsoft / playwright · Issue No. 42740
1.63.0
I have no minimal reproduction to offer, so this is a report of a crash signature and of what has been ruled out, in case it is already known.
A Playwright suite of about 104 tests runs three projects against a Vue app whose main screen is a MapLibre WebGL map. Every API call is stubbed through page.route, so nothing leaves the container. The WebKit project uses devices['iPhone 13'] with a 390x844 viewport, deviceScaleFactor: 3, hasTouch and isMobile. It runs in mcr.microsoft.com/playwright:v1.63.0-noble with --ipc=host, four workers, retries: 0.
docker run --ipc=host ... mcr.microsoft.com/playwright:v1.63.0-noble \
npx playwright test --project=mobile-webkit
The run finishes with no browser process dying.
One to four WebKit web processes die at a random point in every run. The tests they were running fail with Target crashed, with a protocol error naming a closed session, or with an assertion that returns undefined after a few seconds against an element that is unconditionally rendered. Which tests fail changes from run to run, and a test that failed in one run passes in the next. The two Chromium projects run the same specs clean.
Each crash leaves a core dump of about 7 GB of address space (a few hundred megabytes on disk).
Crash signature, headless (WPE):
SIGILL, si_code 2 (ILL_ILLOPN), the faulting address inside webkit-2359/minibrowser-wpe/lib/libWPEWebKit-2.0.so.1.10.2, on a ud2 two bytes past a function's ret. The address differs between crashes.g_atomic_rc_box_release_full: assertion 'real_box->magic == G_BOX_MAGIC' failed, then a series of unrefs on objects that were no longer objects.WebProcess didn't exit as expected after the UI process connection was closed g_error.Crash signature, headed (GTK, under xvfb-run), same suite:
SIGSEGV, SEGV_MAPERR at 0x20, on the main thread, in libwebkitgtk-6.0.so.4 under g_main_context_dispatch inside WTF::RunLoop::run(), with libjavascriptcoregtk-6.0.so.1 frames below it.Both shapes look like a pointer that has been freed or overwritten rather than a resource running out.
The crash is not specific to one browser build. It happens on:
webkit-2359 (WebKit 26.6), the build 1.63.0 installswebkit-2361 (WebKit 26.6), from the browser registrywebkit-2336 (WebKit 26.5), the build 1.62.1 installsJSC_useJIT=falseMeasured and ruled out over about thirty runs:
/dev/shm stayed empty for whole runs, and the container shares the host's IPC namespace.deviceScaleFactor 1 as well as 3.WEBKIT_DISABLE_DMABUF_RENDERER=1, tracing and the screencast turned off, the Mesa shader cache, and the software rasteriser at 24, 2 and 1 threads.One test per run also reported a WebGL INVALID_FRAMEBUFFER_OPERATION on the console, which may be a second symptom of the same fault.
Is this signature known? I am happy to upload a core dump, run a build with symbols, or collect any log the team would find useful.
The host is WSL2, which may well be the relevant difference; I have no second Linux host to compare against.
Relay reads this issue against the repository's contribution signals: the files it is likely to touch, how the maintainers triage work this size, and what the first contribution would exercise.
The full analysis for this issue is still being assembled. Until then, the description above and the thread on GitHub are the most reliable context.