You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ThreadSanitizer: data race in _$LT$std..sys_common..lazy_box..LazyBox$LT$T$GT$$u20$as$u20$core..ops..drop..Drop$GT$::drop::hfc9babc43b28f06f+0x20
#1212
Open
ksolana opened this issue
Nov 18, 2024
· 1 comment
LazyBox is an implementation detail of the standard Mutex (on non-futex platforms). It's possible that we could be causing a race between initialization and destruction of the Mutex due to unsafe code, but I don't think it can happen in this case.
The "read" backtrace is coming through the Registry drop via Arc drop.
The "write" backtrace is in the registry main_loop, which holds one of the Arc counts.
Therefore, the Registry drop can't happen until the synchronized Arc drop completes.
I thinkThreadSanitizer is really complaining about the atomic write vs non-atomic read, but that doesn't understand the Rust semantics that the final Arc handle gets an exclusive &mut to drop its contents, which doesn't need atomic operations anymore.
To repro on Mac
RUSTFLAGS=-Zsanitizer=thread cargo +nightly-2024-08-08 test --profile release-with-debug --target aarch64-apple-darwin
The text was updated successfully, but these errors were encountered: