Data race false positive on once_cell

[matklad]

Hi!

I am excited about the new data race detector, but, unfortunatelly, it fails on once_cell. I think this is a false positive -- I've managed to minimize the test case to do almost literally nothing, and commenting (or uncommenting) a no-op fn is what causes the bug. Here's the repro: matklad/once_cell@93717d9

The test is modified from std: https://github.com/rust-lang/rust/blob/45f638bd8620592b7c50e9b483c2aa8ef9715f5d/library/std/src/sync/once/tests.rs#L17

[RalfJung]

@JCTyblaidd could you have a look at this?

[RalfJung]

The error message is curious:

error: internal compiler error: /rustc/0f6f2d681b39c5f95459cd09cb936b6ceb27cd82/compiler/rustc_mir/src/interpret/validity.rs:918:17: Unexpected error during validation: Data race detected

So this corresponds not to a "normal" memory access but to an access that is implicitly performed by validation. This is probably related to the initialize_inner call.

I noticed the call has an &AtomicUsize as argument. It is possible that validation is doing something that is considered a non-atomic access to this data, which would then probably be a data race.

However, validation doesn't descent through references, so this is odd.

[JCTyblaidd]

Really odd, managed to reduce to

use std::thread::spawn;
pub(crate) struct OnceCell;

impl OnceCell {
    #[cold]
    pub(crate) fn initialize(&self) {
        initialize_inner(&mut || false)
    }
}

fn initialize_inner(_init: &mut dyn FnMut() -> bool) {}

fn main() {
    static O: OnceCell = OnceCell;
    let j1 = spawn(move || {
        O.initialize();
    });
    let j2 = spawn(move || {
        O.initialize();
    });
    j1.join().unwrap();
    j2.join().unwrap();
}

There is no normal memory access associated so my guess is this is some internal miri memory that the race is detected for, looking into it.

[JCTyblaidd]

Reduced to:

use std::thread::spawn;

fn initialize() {
    initialize_inner(&mut || false)
}

fn initialize_inner(_init: &mut dyn FnMut() -> bool) {}

fn main() {
    let j1 = spawn(initialize);
    let j2 = spawn(initialize);
    j1.join().unwrap();
    j2.join().unwrap();
}

It seems to be a data-race in the VTable, are v-tables generated lazily?

[JCTyblaidd]

Looked in rustc_mir/src/interpret/traits.rs, i think its that the vtable is generated lazily in thread 1 and then read by thread 2, since they share the same vtable object and hence memory, so we need to somehow disable race detection when vtables are generated.