Bug 312726
| Summary: | ThreadSanitizer reports false-positive data race on ThreadSafeWeakPtrControlBlock members after relaxed load of control block pointer | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | David Kilzer (:ddkilzer) <ddkilzer> |
| Component: | Web Template Framework | Assignee: | David Kilzer (:ddkilzer) <ddkilzer> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
David Kilzer (:ddkilzer)
ThreadSanitizer (TSan) reports a data race between the non-atomic initialization of `ThreadSafeWeakPtrControlBlock` members and subsequent atomic operations on them (e.g., `WordLock::lock()`).
The `controlBlock()` method in `ThreadSafeRefCountedAndCanMakeThreadSafeWeakPtr` stores the newly allocated control block pointer into `m_bits` with `memory_order_release` to ensure other threads see the initialized ref count and object pointer. However, callers in `ref()`, `deref()`, and the losing-CAS path of `controlBlock()` itself read `m_bits` with `loadRelaxed()` before dereferencing the pointer to access the control block's members. Under the C++ memory model, a relaxed load does not formally synchronize with a release store, so TSan correctly flags the subsequent member access as a data race.
ARM64 dependency ordering and x86 strong ordering make this benign in practice, but the formal C++ memory model requires `memory_order_acquire` on the load to synchronize with the `memory_order_release` store.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/175117037>
David Kilzer (:ddkilzer)
Pull request: https://github.com/WebKit/WebKit/pull/63076
EWS
Committed 311633@main (1ae1abc47aac): <https://commits.webkit.org/311633@main>
Reviewed commits have been landed. Closing PR #63076 and removing active labels.