Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 7d074dda6cbe92376ccdd14d17f5368eabd9ce25
https://github.com/WebKit/WebKit/commit/7d074dda6cbe92376ccdd14d17f5368eabd9ce25
Author: Yijia Huang <[email protected]>
Date: 2026-04-17 (Fri, 17 Apr 2026)
Changed paths:
M Source/JavaScriptCore/wasm/debugger/WasmDebugServer.cpp
M Source/JavaScriptCore/wasm/debugger/WasmExecutionHandler.cpp
Log Message:
-----------
[JSC][WASM][Debugger] Fix ordering bugs in DebugServer::reset() and
ExecutionHandler::reset()
https://bugs.webkit.org/show_bug.cgi?id=312612
rdar://175043884
Reviewed by Mark Lam.
Fix two ordering bugs in the debugger disconnect/reset path.
In DebugServer::reset(), m_executionHandler->reset() was called first, before
m_isDebuggerReady was cleared and the client socket was closed. This meant VM
threads could still enter the debugger trap path (via the lockless
isDebuggerReady
check) or observe a valid socket (via hasDebugger()) while the execution handler
was already being torn down. Fix: clear m_isDebuggerReady and close the socket
first so VM threads are gated out before touching ExecutionHandler.
In ExecutionHandler::reset(), m_breakpointManager->clearAllBreakpoints() was
called after resumeImpl(). resumeImpl() transiently releases m_lock while
waiting
for the VM to resume; in that window, a resumed VM thread could re-hit an active
breakpoint and attempt to stop again, leading to a deadlock. Fix: clear all
breakpoints before calling resumeImpl() while the lock is still held.
Canonical link: https://commits.webkit.org/311504@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
