rustup

[oli-obk]

This doesn't work yet. I get some validation failures around heap allocators:

@RalfJung help!

error: attempted to read undefined bytes
   --> /home/ws/ca8159/Projects/rust/rust/src/libcore/mem.rs:487:5
    |
487 |     intrinsics::uninit()
    |     ^^^^^^^^^^^^^^^^^^^^
    |
note: inside call to alloc::heap::__core::mem::uninitialized::<alloc::allocator::AllocErr>
   --> /home/ws/ca8159/Projects/rust/rust/src/liballoc/heap.rs:83:41
    |
83  |         let mut err = ManuallyDrop::new(mem::uninitialized::<AllocErr>());
    |                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside call to <alloc::heap::Heap as alloc::allocator::Alloc>::alloc
   --> /home/ws/ca8159/Projects/rust/rust/src/liballoc/raw_vec.rs:97:21
    |
97  |                     a.alloc(Layout::from_size_align(alloc_size, align).unwrap())
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside call to <alloc::raw_vec::RawVec<T, A>><u8, alloc::heap::Heap>::allocate_in
   --> /home/ws/ca8159/Projects/rust/rust/src/liballoc/raw_vec.rs:141:9
    |
141 |         RawVec::allocate_in(cap, false, Heap)
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside call to <alloc::raw_vec::RawVec<T>><u8>::with_capacity
   --> /home/ws/ca8159/Projects/rust/rust/src/liballoc/vec.rs:359:18
    |
359 |             buf: RawVec::with_capacity(capacity),
    |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside call to <alloc::Vec<T>><u8>::with_capacity
   --> /home/ws/ca8159/Projects/rust/rust/src/liballoc/slice.rs:163:26
    |
163 |         let mut vector = Vec::with_capacity(s.len());
    |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside call to alloc::slice::hack::to_vec::<u8>
   --> /home/ws/ca8159/Projects/rust/rust/src/liballoc/slice.rs:1509:9
    |
1509|         hack::to_vec(self)
    |         ^^^^^^^^^^^^^^^^^^
note: inside call to alloc::slice::<impl [T]><u8>::to_vec
   --> /home/ws/ca8159/Projects/rust/rust/src/liballoc/slice.rs:1634:9
    |
1634|         self.to_vec()
    |         ^^^^^^^^^^^^^
note: inside call to alloc::slice::<impl alloc::borrow::ToOwned for [T]><u8>::to_owned
   --> /home/ws/ca8159/Projects/rust/rust/src/liballoc/str.rs:189:46
    |
189 |         unsafe { String::from_utf8_unchecked(self.as_bytes().to_owned()) }
    |                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside call to alloc::str::<impl alloc::borrow::ToOwned for str>::to_owned
   --> /home/ws/ca8159/Projects/rust/rust/src/libstd/rt.rs:51:39
    |
51  |         let thread = Thread::new(Some("main".to_owned()));
    |                                       ^^^^^^^^^^^^^^^^^
note: inside call to std::rt::lang_start
   --> /home/ws/ca8159/Projects/rust/rust/src/libstd/rt.rs:32:1
    |
32  | / fn lang_start(main: fn(), argc: isize, argv: *const *const u8) -> isize {
33  | |     use panic;
34  | |     use sys;
35  | |     use sys_common;
...   |
72  | |     }
73  | | }
    | |_^

[oli-obk]

These changes aren't in a nightly yet, so you'll need a custom build rustc

[oli-obk]

The changes are now in the nightly

[RalfJung]

This may have to do something with promoted locals -- it seems there's a 'static borrow that's supposed to be re-acquired, but the memory is gone:

TRACE:rustc_miri::interpret::step:            EndRegion()
TRACE:rustc_miri::interpret::memory:            Releasing frame 10 locks that expire at Some(Node(ItemLocalId(31)))
TRACE:rustc_miri::interpret::validation:            Recovering Local { frame: 10, local: _1 }: &'static str from suspension
TRACE:rustc_miri::interpret::validation:            Recover(Node(ItemLocalId(31))) on Local { frame: 10, local: _1 }: &'static str
TRACE:rustc_miri::interpret::memory:            No suspension around, we can just acquire

[RalfJung]

Something is very confused somewhere. _1 in the above context does not have type &'static str. The suspension is added much earlier, at

TRACE:rustc_miri::interpret::step:           pushing stack frame for promoted0
TRACE:rustc_miri::interpret::step:            _1 = const ""
TRACE:rustc_miri::interpret::eval_context:            _1: Undef
TRACE:rustc_miri::interpret::eval_context:            _1: (Ptr(MemoryPointer { alloc_id: Runtime(2253), offset: 0 }), Bytes(0))
TRACE:rustc_miri::interpret::memory:            Alloc Runtime(2253): (0 bytes, alignment 1) (immutable)
TRACE:rustc_miri::interpret::step:            Validate(Suspend('31s), [_1: &'static str])
TRACE:rustc_miri::interpret::eval_context:            _1: (Ptr(MemoryPointer { alloc_id: Runtime(2253), offset: 0 }), Bytes(0))
TRACE:rustc_miri::interpret::memory:            Alloc Runtime(2253): (0 bytes, alignment 1) (immutable)
TRACE:rustc_miri::interpret::validation:            Suspending Local { frame: 10, local: _1 }: &'static str until Node(ItemLocalId(31))
TRACE:rustc_miri::interpret::validation:            ReleaseUntil(Some(Node(ItemLocalId(31)))) on Local { frame: 10, local: _1 }: &'static str
TRACE:rustc_miri::interpret::memory:            Not touching NoLock at DynamicLifetime { frame: 10, region: None } as its not our lock
TRACE:rustc_miri::interpret::memory:            Adding suspension to NoLock at DynamicLifetime { frame: 10, region: None }

I assume either stack frame numbers get confused somewhere, or I forgot to add some cleanup code somewhere.

[RalfJung]

Okay, I fixed one thing. PR rust-lang/rust#44316 uncovered a bug in validation, namely that suspensions where not cleaned up properly when the function returned.

EDIT: Oh wait, that one didn't even get merged yet. lol
Must be something else then. Or maybe we were just lucky so far and the region IDs have not been clashing across functions?

[RalfJung]

Btw, Travis seems to be rather confused by us using a branch in this repo for this PR. It builds everything twice.

[eddyb]

@RalfJung One can fix this from Travis' settings (and maybe from .travis.yml but I'm not sure), forcing it to only test a fixed set of branches, e.g. only master.

[RalfJung]

Ah, good point, thanks. I restricted it to master for now.

Btw, it turns out that all the tests we had to disable due to backtrace also just ran into this, so they are all reenabled again, plus some more that I had disabled earlier. :)