epoch: Miri reports SB violation

[YoshikiTakashima]

UPDATE(taiki-e): The error originally reported here no longer exists. See #545 (comment) for the remaining SB violations currently reported. The fix for SB violations in epoch exists in #871, and using that branch or using TB (-Zmiri-tree-borrows) instead of SB should fix problems.

---

Hello.

Another MIRI unbounded behavior for destructors, this time in Collector.

 let x1_0: crossbeam::epoch::Collector = crossbeam::epoch::Collector::new();//LAYER:0
 let x2_0: & crossbeam::epoch::Collector = & x1_0;//LAYER:1
 let x3_0: crossbeam::epoch::LocalHandle = x2_0.register();//LAYER:2

Running this gives the MIRI error at deallocation:

error: Undefined Behavior: deallocating while item is protected: [SharedReadWrite for <235744> (call 76130)]
<trace>

I am not super familiar with your internal memory structure, but this may be related to a similar issue seen in another garbage collection implementation. Maybe it will help with the patch.

A code file with a full trace attached. It looks a little weird because the test case was automatically generated.

As for the impact of this issue, it doesn't seem to be too big of an issue as it is mostly contained. Use-after-free should not be possible unless something else happens during dealloc. I can't be 100% sure because Miri stops at that point, but looking at the code in list.rs, it looks okay. It may become more problematic if people start adding more unsafe functions that expose internal memory in some way.

Thanks
~Yoshi

[RalfJung]

The full error message says that this is a Stacked Borrows violation. So, there's an aliasing problem, nothing like use-after-free.

@YoshikiTakashima you could run this with -Zmiri-disable-stacked-borrows to see if other problems show up.

@RalfJung Since the concept of stacked borrows is still in development and shaping up (at least that's my understanding), what's your suggestion on how to treat miri reports like these? Do you think we should strive to eliminate all warnings one by one? Or should we take note of them and wait for stacked borrows to be finalized and accepted into the Rust standard?

[RalfJung]

It would be good to understand what happens, to determine if this is code that should be fixed (and if there is a good way to do that) or a case of Stacked Borrows being too restrictive.

"Deallocated while item is protected" is not a common error, so this seems rather suspicious.

[YoshikiTakashima]

@stjepang and @RalfJung, I reran with -Zmiri-disable-stacked-borrows and it passes fine, no use-after-free, or any other UB except the one we already know. I forgot about this when I rushed some of the evals. Thanks for pointing it out.

[RalfJung]

@stjepang the problem is somewhere in this function:

crossbeam/crossbeam-epoch/src/internal.rs

Lines 615 to 617 in ce53365

	unsafe fn finalize(entry: &Entry, guard: &Guard) {
	guard.defer_destroy(Shared::from(Self::element_of(entry) as *const _));
	}

It looks like one of the two arguments that is passed by reference to this function is actually deallocated while that function is ongoing. That is UB; Rust declares function arguments dereferencable to LLVM which means LLVM may assume that the reference is live throughout the entire execution of the function.

The backtrace goes through this line, so it looks like indeed the entry is being deallocated:

crossbeam/crossbeam-epoch/src/guard.rs

Line 197 in ce53365

local.defer(Deferred::new(move || drop(f())), self);

Miri is actually currently extremely conservative about this kind of error; for good optimizations we likely want to make such liveness assumptions more than we currently do. Some related discussion: rust-lang/unsafe-code-guidelines#88, rust-lang/unsafe-code-guidelines#125.

[jeehoonkang]

It seems entry is immediately destroyed at line 616 without deferred. Actually, I liked Crossbeam's trick of deallocating an object in its own method, but apparently it's "too clever" :) @RalfJung do you have any workaround suggestions for this?

[RalfJung]

@jeehoonkang yeah, use raw pointers for things you want to deallocate. ;)

There's more to this discussion though, Arc has a similar bug: rust-lang/rust#55005. In particular see the lang-team meeting about this and the follow-up discussion that ensued. So another option that we considered besides "use raw pointers" is "do not add dereferencable to types with UnsafeCell". Entry contains an AtomicUsize, so if we applied that work-around on the language level, no changes in crossbeam would be needed.

[divergentdave]

FWIW, Counter in crossbeam-channel exhibits the same behavior, as discussed in rust-lang/miri#1535.

[RalfJung]

It is possible that rust-lang/miri#2248 might help here -- that change is enough to work around rust-lang/rust#55005.