Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: f475b7aaf0ec8173fc791e5739c290240f64ec2c
https://github.com/WebKit/WebKit/commit/f475b7aaf0ec8173fc791e5739c290240f64ec2c
Author: Yijia Huang <[email protected]>
Date: 2026-05-04 (Mon, 04 May 2026)
Changed paths:
M Source/JavaScriptCore/wasm/debugger/WasmExecutionHandler.cpp
M Source/JavaScriptCore/wasm/debugger/WasmExecutionHandler.h
M Source/JavaScriptCore/wasm/debugger/tests/ExecutionHandlerTest.cpp
Log Message:
-----------
[JSC][WASM][Debugger] Use VMIdentifier as stable per-VM thread ID for GDB RSP
replies
https://bugs.webkit.org/show_bug.cgi?id=313911
rdar://176106671
Reviewed by Mark Lam.
The WASM debugger used ownerThreadUID() as the thread ID in GDB RSP replies
to LLDB (qThreadStopInfo, thread-pcs, etc.). This value reflects whichever
OS thread currently holds the JSLock — when a Worker VM's JSLock transfers
to a different thread (e.g. after memory.atomic.wait completes and another
task acquires the VM), the thread ID changes between consecutive stop replies.
LLDB then fails to find the VM in subsequent qThreadStopInfo queries.
Fix: use vm.identifier().toRawValue() — the existing VMIdentifier assigned
to every VM at construction, a sequential uint64 that is stable for the
VM's lifetime regardless of which OS thread holds the JSLock.
Replace all uses of ExecutionHandler::threadId(VM&) with direct access to
vm.identifier().toRawValue(). Remove threadId() entirely since it was the
sole source of the instability. Remove the RELEASE_ASSERTs that compared
Thread::currentSingleton().uid() against threadId() — those comparisons
were checking OS thread identity which is no longer meaningful as the
debugger thread ID.
Canonical link: https://commits.webkit.org/312529@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
