-
Notifications
You must be signed in to change notification settings - Fork 472
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
epoch: Miri reports SB violation #545
Comments
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 |
@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? |
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. |
@stjepang the problem is somewhere in this function: crossbeam/crossbeam-epoch/src/internal.rs Lines 615 to 617 in ce53365
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 crossbeam/crossbeam-epoch/src/guard.rs Line 197 in ce53365
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. |
It seems |
@jeehoonkang yeah, use raw pointers for things you want to deallocate. ;) There's more to this discussion though, |
FWIW, |
It is possible that rust-lang/miri#2248 might help here -- that change is enough to work around rust-lang/rust#55005. |
Does this still occur now that rust-lang/miri#2248 has landed? |
@RalfJung: I believe the original SB violation reported in this issue (rust-lang/rust#55005) no longer exists, but there are several other SB violations. One is the use of pointers that went through methods of Reported error
The fix in #871 was to change And, a similar problem existed in the The last SB violation in epoch was Reported error
The fix in #871 was to use There is also a SB violation in skiplist, but I'm not sure how to fix it. Reported error
EDIT: filed issue #878 for SB violation in skiplist |
796: epoch: Remove ptr-to-int casts r=taiki-e a=taiki-e Use [this hack](rust-lang/miri#1866 (comment)) to fix compatibility issues with Miri (see #490 (comment) for details). Due to the #545, still not compatible with stacked borrows. This will be fixed by the subsequent PR (#871). Note: this is a breaking change because changes API of Pointable and Pointer traits Fixes #579 881: Remove deprecated items r=taiki-e a=taiki-e This removes the following deprecated items: - crossbeam-epoch: - `CompareAndSetError` - `CompareAndSetOrdering` - `Atomic::compare_and_set` - `Atomic::compare_and_set_weak` - crossbeam-utils: - `AtomicCell::compare_and_swap` Co-authored-by: Taiki Endo <[email protected]>
796: epoch: Remove ptr-to-int casts r=taiki-e a=taiki-e Use [this hack](rust-lang/miri#1866 (comment)) to fix compatibility issues with Miri (see #490 (comment) for details). Due to the #545, still not compatible with stacked borrows. This will be fixed by the subsequent PR (#871). Note: this is a breaking change because changes API of Pointable and Pointer traits Fixes #579 Co-authored-by: Taiki Endo <[email protected]>
The SB error with With SB the provenance of references is restricted to the range of the type that the reference points to. Whereas, with TB this aspect is relaxed, which seems to align with this error not showing up under TB. I think this is complicated by the container type being |
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.
Running this gives the MIRI error at deallocation:
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
The text was updated successfully, but these errors were encountered: