Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 8dbd1997c887813d5e85f1775b77ffda8d179e29
https://github.com/WebKit/WebKit/commit/8dbd1997c887813d5e85f1775b77ffda8d179e29
Author: Yijia Huang <[email protected]>
Date: 2026-09-17 (Thu, 17 Sep 2026)
Changed paths:
M JSTests/wasm/debugger/lib/session.py
M JSTests/wasm/debugger/resources/wasm/multi-instance-unreachable.js
M JSTests/wasm/debugger/tests/tests.py
Log Message:
-----------
[JSC] WASM debugger tests: fix a prologue-attach flake and a silent JSC exit
https://bugs.webkit.org/show_bug.cgi?id=324357
rdar://187592091
Reviewed by Yusuke Suzuki.
Two independent test-infrastructure fixes.
MultiInstanceUnreachableStepTestCase flaked under -p. An attach can land in a
wasm
prologue, one of the two safepoints JSC services interrupts at, and a prologue
stop
is reported at the function's first body instruction because setPrologueStopData
builds the address from callee->bytecode(). A test that breakpoints that address
therefore has LLDB believing the process is already stopped on the site: the
next
resume runs z0/step/Z0, lifting the patch exactly when the program arrives, so
the
arrival is never reported. That only loses a test when something stops the
debugger
before execution comes back round, which is why 26 other tests breakpoint a
first
instruction and still pass. Here the step lands on `unreachable`, so the resume
traps and the first `c` reports the trap instead of breakpoint 2.
multi-instance-unreachable.js therefore carries two leading nops: the first
keeps
`unreachable` itself off the first instruction, which is the permanent form of
the
same collision, and the second does the same for this test's breakpoint. The
four
tests on that fixture move up a byte. The bare si gains a pattern for where the
step
landed, which makes the dis that followed it redundant.
DEBUGGER_READY is printed by the JS fixture, so it says nothing about whether
the
debug server bound its port. JSC exits when it cannot bind and reports that only
under --verbose-wasm-debugger, so the session waited out its full 60 s and then
blamed the missing banner rather than the exit. The wait now polls the process
and
raises as soon as it is gone, quoting the exit code -- 60 s becomes 0.1 s. A
bind
that fails without taking the process down is still caught after the wait as
before.
Canonical link: https://commits.webkit.org/321325@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
