Memory leak checker misses AtomicPtr

[cynecx]

use std::{
    cell::UnsafeCell,
    ptr,
    sync::atomic::{AtomicPtr, Ordering},
};

fn leak() {
    static LEAK: AtomicPtr<usize> = AtomicPtr::new(ptr::null_mut());
    LEAK.store(Box::into_raw(Box::new(0usize)), Ordering::SeqCst);
}

fn no_leak() {
    struct Local(UnsafeCell<*mut usize>);

    unsafe impl Send for Local {}
    unsafe impl Sync for Local {}

    static LEAK: Local = Local(UnsafeCell::new(ptr::null_mut()));
    *unsafe { &mut *LEAK.0.get() } = Box::into_raw(Box::new(0usize));
}

fn main() {
    no_leak();
    // leak();
}

Miri considers memory leaks reachable through a static global as non-leaking. I'd expect the Atomic* case be non-leaking as well, however miri reports it as leaked memory.

The following memory was leaked: alloc1834 (Rust heap, size: 8, align: 8) {
    00 00 00 00 00 00 00 00                         │ ........
}

error: the evaluated program leaked memory

error: aborting due to previous error; 1 warning emitted

(This is a special case of #1618.)

[bjorn3]

AtomicPtr casts the pointer to an integer before storing it. This prevents miri from seeing that the AtomicPtr keeps it alive.

[oli-obk]

So... we can either not do a cast in AtomicPtr (I guess a transmute will keep the provenance?) or we need to teach AtomicPtr to set the miri_static_root (but that would be overly permissive, as you could now also just do that in non-static code).

[RalfJung]

Yeah, I cannot think of a good way to fix this I am afraid... we cannot just randomly cast any integer we see to a pointer in the off chance that it represents an actual address. Ideally AtomicPtr would not cast pointers to integers, but the underlying problem here is that LLVM does not support atomic operations on pointers. I guess we could push this down to the LLVM codegen layer so that the Rust intrinsic does support pointers, not sure if that would be a good idea.

Probably I should not have closed #1318, which is the same problem. Crossbeam is also affected by this (crossbeam-rs/crossbeam#464).

Currently the best way to approach the problem is to call miri_static_root.

[oli-obk]

I guess we could push this down to the LLVM codegen layer so that the Rust intrinsic does support pointers, not sure if that would be a good idea.

Oh, I like this. That seems entirely reasonable to me

[oli-obk]

the underlying problem here is that LLVM does not support atomic operations on pointers

I was unable to find any recent information on this being true and changing it in rustc to just use pointers worked without any additional changes.

[RalfJung]

Uh I thought I had LLVM experts confirm that when I asked but maybe I misremember.

[RalfJung]

FWIW, this is also a problem when using -Zmiri-track-raw-pointers, which breaks int-to-ptr casts -- both Windows in general, and accessing the program arguments on Unix systems, involve AtomicPtr and thus fail with -Zmiri-track-raw-pointers.