Miri detects UB (SB error) when setting a thread name

[saethlin]

I tried this code:

fn main() {
    std::thread::Builder::new()
        .name("name".to_string())
        .spawn(|| {})
        .unwrap()
        .join()
        .unwrap();
}

MIRIFLAGS="-Zmiri-tag-raw-pointers" cargo miri run

I expected to see this happen: Nothing

Instead, this happened: Miri is upset 😢

error: Undefined Behavior: no item granting read access to tag <untagged> at alloc1582 found in borrow stack.
   --> /home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/unix/thread.rs:125:13
    |
125 |             libc::prctl(PR_SET_NAME, name.as_ptr() as libc::c_ulong, 0, 0, 0);
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no item granting read access to tag <untagged> at alloc1582 found in borrow stack.
    |
    = help: this indicates a potential bug in the program: it performed an invalid operation, but the rules it violated are still experimental
    = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
            
    = note: inside `std::sys::unix::thread::Thread::set_name` at /home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/unix/thread.rs:125:13
    = note: inside closure at /home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:467:17
    = note: inside `<[closure@std::thread::Builder::spawn_unchecked<[closure@src/main.rs:4:16: 4:21], ()>::{closure#1}] as std::ops::FnOnce<()>>::call_once - shim(vtable)` at /home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
    = note: inside `<std::boxed::Box<dyn std::ops::FnOnce()> as std::ops::FnOnce<()>>::call_once` at /home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1811:9
    = note: inside `<std::boxed::Box<std::boxed::Box<dyn std::ops::FnOnce()>> as std::ops::FnOnce<()>>::call_once` at /home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1811:9
    = note: inside `std::sys::unix::thread::Thread::new::thread_start` at /home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/unix/thread.rs:108:17

I truly have no idea what's going on here. I've tried a number of things with moving data or pointers to data into threads, and none of them can trip up the Stacked Borrows tracking. cc @RalfJung ?

[5225225]

I vaguely remember a previous issue where pointer -> int casts tripped up stacked borrows when used in a syscall like that.

I'd need to go find it, but IIRC the (proposed, i don't think tested) solution was to transmute if cfg!(miri)?

[RalfJung]

Yeah, the <untagged> is the smoking gun here -- good catch.

Int-to-ptr casts do not work with -Zmiri-tag-raw-pointers.

[saethlin]

Wow that's awkward. So we're backed into a corner here by the combination of this miri peculiarity and the signature of this libc function, because it is trying to be generic.

Is this something better fixed in miri?

[RalfJung]

It seems at least better to track this in Miri, so I moved the issue.

[RalfJung]

Actually, we already have this issue on the Miri side: #1717