Possible issue found with Miri about lru-rs

[Firstyear]

I think there are some ways to do that ... let me look into the miri exclusion. But I'm also happy to put in a PR to improve this, so hopefully I have some time this week :)

Thanks for your patience with me on this!

[jeromefroe]

Hey! Thanks for reporting this. Can you also provide the command that you're using to run miri? When I run it locally myself I don't get any errors:

$ cargo miri run --target x86_64-unknown-linux-gnu
   Compiling compiler_builtins v0.1.27
    Checking core v0.0.0 (/Users/jeromefroelich/.rustup/toolchains/nightly-2020-05-09-x86_64-apple-darwin/lib/rustlib/src/rust/src/libcore)
   Compiling cc v1.0.50
   Compiling libc v0.2.69
   Compiling autocfg v0.1.7
   Compiling std v0.0.0 (/Users/jeromefroelich/.rustup/toolchains/nightly-2020-05-09-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd)
   Compiling hashbrown v0.6.2
   Compiling backtrace-sys v0.1.37
   Compiling unwind v0.0.0 (/Users/jeromefroelich/.rustup/toolchains/nightly-2020-05-09-x86_64-apple-darwin/lib/rustlib/src/rust/src/libunwind)
    Checking rustc-std-workspace-core v1.99.0 (/Users/jeromefroelich/.rustup/toolchains/nightly-2020-05-09-x86_64-apple-darwin/lib/rustlib/src/rust/src/tools/rustc-std-workspace-core)
    Checking cfg-if v0.1.10
    Checking alloc v0.0.0 (/Users/jeromefroelich/.rustup/toolchains/nightly-2020-05-09-x86_64-apple-darwin/lib/rustlib/src/rust/src/liballoc)
    Checking rustc-demangle v0.1.16
    Checking panic_abort v0.0.0 (/Users/jeromefroelich/.rustup/toolchains/nightly-2020-05-09-x86_64-apple-darwin/lib/rustlib/src/rust/src/libpanic_abort)
    Checking backtrace v0.3.46
    Checking rustc-std-workspace-alloc v1.99.0 (/Users/jeromefroelich/.rustup/toolchains/nightly-2020-05-09-x86_64-apple-darwin/lib/rustlib/src/rust/src/tools/rustc-std-workspace-alloc)
    Checking panic_unwind v0.0.0 (/Users/jeromefroelich/.rustup/toolchains/nightly-2020-05-09-x86_64-apple-darwin/lib/rustlib/src/rust/src/libpanic_unwind)
    Finished release [optimized] target(s) in 19.89s
    Checking rustc-std-workspace-std v1.99.0 (/Users/jeromefroelich/.rustup/toolchains/nightly-2020-05-09-x86_64-apple-darwin/lib/rustlib/src/rust/src/tools/rustc-std-workspace-std)
    Checking proc_macro v0.0.0 (/Users/jeromefroelich/.rustup/toolchains/nightly-2020-05-09-x86_64-apple-darwin/lib/rustlib/src/rust/src/libproc_macro)
    Checking term v0.0.0 (/Users/jeromefroelich/.rustup/toolchains/nightly-2020-05-09-x86_64-apple-darwin/lib/rustlib/src/rust/src/libterm)
    Checking unicode-width v0.1.6
    Checking getopts v0.2.21
    Checking test v0.0.0 (/Users/jeromefroelich/.rustup/toolchains/nightly-2020-05-09-x86_64-apple-darwin/lib/rustlib/src/rust/src/libtest)
    Finished release [optimized] target(s) in 2.58s

[Firstyear]

Hey there,

I think the issue is here https://github.com/jeromefroe/lru-rs/blob/master/src/lib.rs#L222

It looks like you are making a new MaybeUninit, and then immediately calling https://doc.rust-lang.org/std/mem/union.MaybeUninit.html#method.assume_init on it, which can't be valid because you don't have an LruEntry inside the MaybeUninit at that point I think. This is what appears to confuse the ManualDrop::into_inner because there is no pointer inside of the MaybeUninit at that point.

Anyway, I'm running this from my concread library, and the commands would be:

git clone https://github.com/Firstyear/concread.git
cargo clean && cargo miri setup && cargo miri test -- -Zmiri-disable-isolation -- test_cache_concurrent_cursed_1

Which should give you the error.

Hope that helps, and thanks for your time :)

[jeromefroe]

Ahh, so I believe that should be okay because we implement Drop for the LruCache where we handle the head and tail entries specially. We never initialize head and tail normally, but that's okay because we only ever use the next and prev fields of them.

[Firstyear]

I guess the challenge is while it's okay and we know it's okay, convincing miri to agree with that situation :)

Maybe it's not my place to say, but perhaps the way to resolve this is have MaybeUninit K, V in the LruEntry itself rather than in the Box so you can initialise the sigil nodes, or to remove the sigil nodes and set head/tail to ptr::null_mut() and change the double linked list algorithm to suit.

[jeromefroe]

Yea, is there a way to exclude lines from Miri? That might be the simplest solution. PR's are also more than welcome if you have any other implementation ideas :)

[Firstyear]

This PR relates to this issue #74

Thanks!

[Firstyear]

Also as a note, it's not possible to provide a miri exclusion beyond the granularity of excluding a whole test, so we can't just mask this one area from examination.

[jeromefroe]

Closing this now that #74 has landed.