Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 08f5b5c35ece28a8bae48569a6ded550ae396449
https://github.com/WebKit/WebKit/commit/08f5b5c35ece28a8bae48569a6ded550ae396449
Author: Yijia Huang <[email protected]>
Date: 2026-09-15 (Tue, 15 Sep 2026)
Changed paths:
A JSTests/wasm/debugger/resources/wasm/multi-instance-global.js
M JSTests/wasm/debugger/tests/tests.py
M Source/JavaScriptCore/jsc.cpp
M Source/JavaScriptCore/runtime/VM.cpp
M Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.cpp
M Source/JavaScriptCore/wasm/debugger/WasmDebugServer.cpp
M Source/JavaScriptCore/wasm/debugger/WasmDebugServer.h
M Source/JavaScriptCore/wasm/debugger/WasmExecutionHandler.cpp
M Source/JavaScriptCore/wasm/debugger/WasmModuleManager.cpp
M Source/JavaScriptCore/wasm/debugger/WasmModuleManager.h
M Source/JavaScriptCore/wasm/debugger/WasmQueryHandler.cpp
M Source/JavaScriptCore/wasm/debugger/WasmVirtualAddress.cpp
M Source/JavaScriptCore/wasm/debugger/WasmVirtualAddress.h
M Source/JavaScriptCore/wasm/debugger/tests/ExecutionHandlerTestSupport.cpp
M Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.h
M Source/WebKit/WebProcess/Inspector/WasmDebuggerDispatcher.cpp
Log Message:
-----------
[JSC] WASM debugger: unencodable instance-id sentinel, clearer predicate
names, and a loud failure when the server cannot start
https://bugs.webkit.org/show_bug.cgi?id=324189
rdar://187408850
Reviewed by Yusuke Suzuki.
JSWebAssemblyInstance::m_debugId defaulted to 0, which is a valid instance id.
An instance the debugger never registered therefore encoded as instance 0, so
its virtual addresses silently aliased a real instance's. It now defaults to
VirtualAddress::INVALID_ID, which a static_assert pins above MAX_ID so it can
never encode, and toVirtual() asserts on it rather than producing an address.
m_debugId and its accessors move behind ENABLE(WEBASSEMBLY_DEBUGGER).
Every path that can hand an unregistered instance to the debugger funnels
through toVirtual(), so that one assert covers them all and no call site needs
its own check. The option can still be set in an embedder that never calls
start() or startRWI(), but that is a misconfiguration and should fail loudly
rather than silently not debug.
jsc discarded start()'s result, so a port already in use produced a process that
was neither debuggable nor representative - enabling the debugger also forces
BBQ and OMG off - with nothing said about why. It now reports the failure and
exits.
needsLibraryRequery() swept dead instances without re-arming the amortized
cleanup budget; since the budget is sized off the surviving instance count,
re-arming now happens at the end of sweepDeadInstances() itself and
cleanupHappened() is gone. The two were never useful apart, and separating them
is what let a caller forget one. registerInstance()'s id-bound assert also moves
above the post-increment so it reads against the counter it constrains; the same
value is tested either way.
Renamed for clarity, no behaviour change: hasDebugger() -> isConnected(), since
it tests whether sendReply() has anywhere to go and collided with the unrelated
JSGlobalObject::hasDebugger(); isDebuggerReady() -> hasSentLibraryList(), since
the IPC message WasmDebugServerReady already names the opposite rung of the
lattice. WasmDebugServer.h now carries a lifecycle diagram and a comment per
predicate - isConnected() in particular is constant-true in a WebContent
process, because startRWI() registers the response handler and nothing
unregisters it.
Tests:
JSTests/wasm/debugger/tests/tests.py: MultiInstanceGlobalTestCase
Canonical link: https://commits.webkit.org/321224@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
