Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 4a78281a5504f78bcfbfda4fb6a99b3a591b8379
https://github.com/WebKit/WebKit/commit/4a78281a5504f78bcfbfda4fb6a99b3a591b8379
Author: Yijia Huang <[email protected]>
Date: 2026-01-17 (Sat, 17 Jan 2026)
Changed paths:
M Source/JavaScriptCore/runtime/JSLock.h
M Source/JavaScriptCore/runtime/VM.h
M Source/JavaScriptCore/wasm/debugger/WasmExecutionHandler.cpp
Log Message:
-----------
[JSC][WASM][Debugger] Avoid RefPtr operations during thread suspension to fix
deadlock
https://bugs.webkit.org/show_bug.cgi?id=305674
rdar://168319182
Reviewed by Yusuke Suzuki.
The WASM debugger can deadlock when Thread #8 suspends Thread #4 via
thread_suspend() while Thread #4 is in the middle of ref counting operations.
The suspended thread may hold a WordLock (used for thread-safe ref counting),
and when the suspending thread tries to create a RefPtr copy, it blocks
waiting for the same lock.
The deadlock sequence:
1. Thread #4 acquires WordLock in strongDeref() destructor
2. Thread #8 suspends Thread #4 via thread_suspend() Mach kernel trap
3. Thread #4 is frozen mid-unlock, WordLock never released
4. Thread #8's lambda calls vm.apiLock().ownerThread(), creating RefPtr copy
5. RefPtr copy triggers strongRef() which tries to acquire same WordLock
6. Deadlock: Thread #4 suspended holding lock, Thread #8 blocked waiting
The fix adds ownerThreadUID() methods that return the thread UID directly
without creating temporary RefPtr objects, avoiding all ref counting
operations and the associated lock contention.
Canonical link: https://commits.webkit.org/305766@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
