[Bug]: WebKit (WPE) web process aborts at exit in PlatformDisplay::sharedDisplay() since 1.64 (webkit-2370)
メンテナーはふだん 1 日以内に返信
@yury-s がすでに取り組んでいます。
2026年10月14日 から。
評価
この issue はまだ評価されていません。
説明
Version
1.64.1 (webkit-2370). Also 1.65.0-alpha-2026-10-14 (webkit-2375).
Steps to reproduce
The host must store core dumps, for example with systemd-coredump. The machine has no GPU. WebKit renders with Mesa llvmpipe.
-
Make a folder
foowith these three files.playwright.config.ts:import { defineConfig } from '@playwright/test'; export default defineConfig({ testDir: '.', workers: 16, timeout: 120_000, use: { browserName: 'webkit' }, webServer: { command: 'node server.js', url: 'http://127.0.0.1:8080/' }, });bar.spec.ts:import { test, expect } from '@playwright/test'; // One browser, many contexts: each closed context ends its web process while the browser stays up. test('opens and closes 50 contexts', async ({ browser }) => { for (let i = 0; i < 50; i++) { const context = await browser.newContext(); const page = await context.newPage(); await page.goto(`http://127.0.0.1:8080/foo/${i}`); await expect(page.locator('h1')).toContainText('bar'); await context.close(); } });server.js:// Serves the same page for every path: a large DOM and a large JavaScript heap, so that tearing the page down takes a while. require('http').createServer((req, res) => { res.setHeader('content-type', 'text/html'); res.end(`<!doctype html><title>foo</title><h1>bar ${req.url}</h1><div id="foo"></div> <script> const foo = document.getElementById('foo'); for (let i = 0; i < 50000; i++) foo.appendChild(document.createElement('span')).textContent = i + ' '; window.bar = Array.from({ length: 1000000 }, (_, i) => ({ i, s: 'x' + i })); </script>`); }).listen(8080); -
Run it in the official image. This closes 800 contexts:
cd foo docker run --rm --ipc=host --init --user 1000:1000 -e HOME=/tmp \ -e WEBKIT_SKIA_ENABLE_CPU_RENDERING=1 \ -v "$PWD:/foo:ro" mcr.microsoft.com/playwright:v1.64.1-noble \ bash -c 'cp -r /foo /tmp/w && cd /tmp/w && npm i --silent @playwright/[email protected] && npx playwright test --repeat-each=16 --reporter=dot' -
Count the cores:
coredumpctl list | grep WPEWebProcess.
WEBKIT_SKIA_ENABLE_CPU_RENDERING=1 makes this small repro hit the crash. Without it, the repro gives no cores on our machine.
Expected behavior
All tests pass, and every web process exits cleanly.
Actual behavior
All tests pass, but web processes abort after their page closes:
Running 16 tests using 16 workers
················
16 passed (1.6m)
$ coredumpctl list | grep WPEWebProcess | wc -l
32
$ coredumpctl list | grep WPEWebProcess | head -3 | cut -d' ' -f5-
212999 1000 1000 SIGABRT present /ms-playwright/webkit-2370/minibrowser-wpe/bin/WPEWebProcess 19.4M
214541 1000 1000 SIGABRT present /ms-playwright/webkit-2370/minibrowser-wpe/bin/WPEWebProcess 20.4M
215532 1000 1000 SIGABRT present /ms-playwright/webkit-2370/minibrowser-wpe/bin/WPEWebProcess 19.4M
A second run of the same command gave 22 cores, all SIGABRT.
gdb on one core (webkit-2370). The offsets are from the load base of libWPEWebKit-2.0.so.1, which has no debug symbols:
Program terminated with signal SIGABRT, Aborted.
#4 __GI_abort () at ./stdlib/abort.c:79
#5 libWPEWebKit-2.0.so.1 +0x8255e7 WTFCrashWithInfo
#6 libWPEWebKit-2.0.so.1 +0x2f54e36 WebCore::PlatformDisplay::sharedDisplay()
#7 libWPEWebKit-2.0.so.1 +0x2f62ea2 (see below)
#8 libWPEWebKit-2.0.so.1 +0x25be7db RunLoop timer dispatch
#9 libWPEWebKit-2.0.so.1 +0x25bcc56
#10 libglib-2.0.so.0
#11 g_main_context_dispatch ()
#12 libWPEWebKit-2.0.so.1 +0x25bd2c1 run loop iteration
#13 libWPEWebKit-2.0.so.1 +0x25bd5d7
#14 WebKit::WebProcessMain(int, char**) ()
Frame 6 passes these arguments to WTFCrashWithInfo:
line 0x44 (68)
"/home/pwuser/webkit/Source/WebCore/platform/graphics/PlatformDisplay.cpp"
"static PlatformDisplay &WebCore::PlatformDisplay::sharedDisplay()"
This is RELEASE_ASSERT(s_sharedDisplay) in PlatformDisplay::sharedDisplay(). A core from webkit-2375 shows the same arguments.
Frame 7 looks like BitmapTexturePool::releaseUnusedTexturesTimerFired(). We matched it by its machine code, because the library has no symbols. It takes the lock, checks m_textures and m_imageTextures, calls GLContextWrapper::currentContext(), and then calls PlatformDisplay::sharedDisplay().sharingGLContext().
Additional context
We think the fix for WebKit bug 305909 (e0b1fdd) causes this. Playwright 1.64 shipped that fix for #42940. The fix makes WebProcess::stopRunLoop() call PlatformDisplay::destroySharedDisplay(). BitmapTexturePool keeps a RunLoop::Timer on the main run loop with priority RunLoopSourcePriority::ReleaseUnusedResourcesTimer. The RunLoop::dispatch() source, which delivers didClose, has priority RunLoopSourcePriority::RunLoopDispatcher. In wtf/glib/RunLoopSourcePriority.h, both values are 0 on WPE (on GTK they are 200 and 100). When both sources are ready in one main loop iteration, stopRunLoop() runs first and destroys the display. Then the pool timer runs and calls sharedDisplay(), which aborts. A slow page teardown makes this more likely. That is why the repro uses a large page.
Possible fixes: use sharedDisplayIfExists() in releaseUnusedTexturesTimerFired(), or stop the pool timer in destroySharedDisplay().
Repro results, 800 context closes per run:
| Playwright | WebKit | Skia | WebKit cores |
|---|---|---|---|
| 1.63.0 | 2359 | GPU (default) | 0 |
| 1.63.0 | 2359 | CPU | 0 |
| 1.64.1 | 2370 | GPU (default) | 0 |
| 1.64.1 | 2370 | CPU | 31, 25, 32, 22 SIGABRT (four runs) |
| 1.65.0-alpha-2026-10-14 | 2375 | CPU | 37 SIGABRT |
We also see this abort, with the same frames, in a larger private test suite on 1.64.1. The tests still pass, but each crash writes a core dump.
Environment
OS: Linux x86_64, Docker
Image: mcr.microsoft.com/playwright:v1.64.1-noble (Ubuntu 24.04.5)
Node: 24.21.0
@playwright/test: 1.64.1
WebKit: webkit-2370 (minibrowser-wpe), headless
Graphics: no GPU, Mesa 25.2.8 llvmpipe
- 主要言語
- TypeScript
- スター
- 99.1k
- フォーク
- 6.8k
- 平均マージ
- 16時間 20分
- マージ済み PR(30日)
- 324
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/playwright のほかの issue
-
needs-triage
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
microsoft/playwright#43969 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
needs-triage
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
microsoft/playwright#43967 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
needs-triage
難易度 4/5 3〜5日 初心者へのやさしさ 57/100
microsoft/playwright#43966 · コメント 5 件 ·
メンテナーはふだん 1 日以内に返信
-
[Bug]: page.screenshot({ fullPage: true }) times out on SVG documents (no document.body)対応中かも @microsoft-playwright-automation が 1 日前に担当しました。 オープンneeds-triage
難易度 3/5 1〜2日 初心者へのやさしさ 25/100
microsoft/playwright#43962 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
needs-triage
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
microsoft/playwright#43926 · コメント 4 件 ·
メンテナーはふだん 1 日以内に返信
microsoft/playwright の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
documentation easy good first issue help wanted
難易度 1/5 1〜3時間 初心者へのやさしさ 83/100
メンテナーはふだん 1 日以内に返信
-
Billion-context documentation addendum: nudge is independent of window occupancy. | billion-context 文档补充:nudge 与窗口占用无关対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 1/5 1〜3時間 初心者へのやさしさ 86/100
ranxianglei/billion-context#5893 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 79/100
microsoft/monaco-editor#5575 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100