1590423 - TSan: Rust data races reported in Arc due to use of fences

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Christian Holler (:decoder)]

TSan is reporting data races like this:

WARNING: ThreadSanitizer: data race (pid=26501)                                                                                                            
  Write of size 8 at 0x7b0800064d80 by main thread (mutexes: write M1018511757209198976):                                                          
    #0 free <null> (xpcshell+0x31388)                                                                                                   
    #1 _$LT$alloc..sync..Arc$LT$T$GT$$u20$as$u20$core..ops..drop..Drop$GT$::drop::h3d4e60bfc586ef93 /rustc/7979016aff545f7b41cc517031026020b340989d/src/liballoc/sync.rs:1234:12 (libxul.so+0xac6d8a4)
    #2 core::ptr::real_drop_in_place::hdfa697d9f5df0369 /rustc/7979016aff545f7b41cc517031026020b340989d/src/libcore/ptr/mod.rs:175 (libxul.so+0xac6d8a4)
    #3 core::ptr::real_drop_in_place::he664d27ab51b4292 /rustc/7979016aff545f7b41cc517031026020b340989d/src/libcore/ptr/mod.rs:175 (libxul.so+0xac6d8a4)
    #4 std::sync::mpsc::blocking::WaitToken::wait::h9692c7d7b0473411 /rustc/7979016aff545f7b41cc517031026020b340989d/src/libstd/sync/mpsc/blocking.rs:73:4 (libxul.so+0xac6d8a4)                                   
    #5 std::sync::mpsc::Receiver$LT$T$GT$::recv::hfc74dd62ee44bedd /rustc/7979016aff545f7b41cc517031026020b340989d/src/libstd/sync/mpsc/mod.rs:1189:26 (libxul.so+0xadeea22)             
    #6 audioipc::core::spawn_thread::h6152cf8d4ffa5f7e media/audioipc/audioipc/src/core.rs:69:17 (libxul.so+0xadc45d7)                                                       
[...]      
  Previous atomic write of size 8 at 0x7b0800064d80 by thread T21:
    #0 __tsan_atomic64_fetch_sub <null> (xpcshell+0x7f451)
    #1 core::sync::atomic::atomic_sub::h07ac1884824fa2c3 /rustc/7979016aff545f7b41cc517031026020b340989d/src/libcore/sync/atomic.rs:2187:19 (libxul.so+0xb66bc53)
    #2 core::sync::atomic::AtomicUsize::fetch_sub::h149d10c4fb6ce7c5 /rustc/7979016aff545f7b41cc517031026020b340989d/src/libcore/sync/atomic.rs:1584:29 (libxul.so+0xb66bda1)
    #3 _$LT$alloc..sync..Arc$LT$T$GT$$u20$as$u20$core..ops..drop..Drop$GT$::drop::h5d8e06f4eb0141ff /rustc/7979016aff545f7b41cc517031026020b340989d/src/liballoc/sync.rs:1199:11 (libxul.so+0xb66c451)
    #4 core::ptr::real_drop_in_place::h22c5867e303ffc3b /rustc/7979016aff545f7b41cc517031026020b340989d/src/libcore/ptr/mod.rs:175 (libxul.so+0xb66ad99)
    #5 core::ptr::real_drop_in_place::h771635375b0538a3 /rustc/7979016aff545f7b41cc517031026020b340989d/src/libcore/ptr/mod.rs:175 (libxul.so+0xb66afc9)
    #6 std::sync::mpsc::oneshot::Packet$LT$T$GT$::send::h804320b90958b275 /rustc/7979016aff545f7b41cc517031026020b340989d/src/libstd/sync/mpsc/oneshot.rs:112:62 (libxul.so+0xb66a3b7)
    #7 std::sync::mpsc::Sender$LT$T$GT$::send::h9b4916e5859a6532 /rustc/7979016aff545f7b41cc517031026020b340989d/src/libstd/sync/mpsc/mod.rs:815:27 (libxul.so+0xadee7fa)
    #8 audioipc::core::spawn_thread::_$u7b$$u7b$closure$u7d$$u7d$::h63034412fc25d4cc media/audioipc/audioipc/src/core.rs:58:13 (libxul.so+0xb674d87)
[...]

According to :stko, one of the Rust community members, TSan does not implement support for fences and hence race reports involving Arc are expected. They suggest to patch Rust to solve this problem. For now, we should just suppress races involving sync..Arc to unblock the build (these races trigger during make check).

Comment 1

[Christian Holler (:decoder)]

Attachment: Bug 1590423 - Suppress races related to Rust std::sync::Arc. r?jseward

Comment 2

[Julian Seward [:jseward]]

r+'d.

I should perhaps add: back in the days of Helgrind, I managed to annotate the
release methods in Gecko's thread-safe ref-counted-object C++ classes so
that Helgrind "understood" them. In particular, so that it understood that
the thread making a release call that causes the refcount to transition from
1 to 0 always "happens-after" a release call on the same object that causes
a refcount transition from n+1 to n, for n > 0. This meant Helgrind "knows"
that the thread causing the 1-to-0 transition can now safely access and free
the block without locking.

That requires having annotations available to describe arbitrary
happens-before edges. I imagine TSan might well have those, in which case it
is an interesting question as to whether Rust's Arc support can be annotated
accordingly.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/acf10a908295
Suppress races related to Rust std::sync::Arc. r=jseward

Comment 4

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/acf10a908295