Skip to content

"cargo miri run" fails: cannot alloc memory for unsized type #675

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
RalfJung opened this issue Apr 6, 2019 · 8 comments
Closed

"cargo miri run" fails: cannot alloc memory for unsized type #675

RalfJung opened this issue Apr 6, 2019 · 8 comments
Labels
A-interpreter Area: affects the core interpreter C-bug Category: This is a bug.

Comments

@RalfJung
Copy link
Member

RalfJung commented Apr 6, 2019

Our nightly CI job failed in a surprising way:

thread 'rustc' panicked at 'cannot alloc memory for unsized type', src/librustc_mir/interpret/place.rs:942:13
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:478
   6: std::panicking::begin_panic
   7: rustc_mir::interpret::place::<impl rustc_mir::interpret::eval_context::InterpretCx<M>>::allocate
   8: rustc_mir::interpret::step::<impl rustc_mir::interpret::eval_context::InterpretCx<M>>::run
   9: miri::eval_main
  10: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  11: rustc_interface::passes::create_global_ctxt::{{closure}}
  12: rustc_interface::passes::BoxedGlobalCtxt::enter
  13: <miri::MiriCompilerCalls as rustc_driver::Callbacks>::after_analysis
  14: rustc_interface::interface::run_compiler_in_existing_thread_pool
  15: std::thread::local::LocalKey<T>::with
  16: scoped_tls::ScopedKey<T>::set
  17: syntax::with_globals
query stack during panic:
end of query stack

That is with rust-lang/rust@b025802a2. CI on the last PR worked fine. Hence the offending commit is in rust-lang/rust@f717b58...b025802.

@RalfJung
Copy link
Member Author

RalfJung commented Apr 6, 2019

The end of the trace is

 INFO 2019-04-06T09:13:01Z: rustc_mir::interpret::eval_context: PAUSING(7) std::sys_common::at_exit_imp::cleanup
 INFO 2019-04-06T09:13:01Z: rustc_mir::interpret::eval_context: ENTERING(8) <std::boxed::Box<dyn std::boxed::FnBox<(), Output = ()>> as std::ops::FnOnce<()>>::call_once
 INFO 2019-04-06T09:13:01Z: rustc_mir::interpret::step: // bb0
 INFO 2019-04-06T09:13:01Z: rustc_mir::interpret::step: Retag([fn entry] _1)
 INFO 2019-04-06T09:13:01Z: rustc_mir::interpret::step: Retag([fn entry] _2)
 INFO 2019-04-06T09:13:01Z: rustc_mir::interpret::step: StorageLive(_3)

so this is likely caused by rust-lang/rust#59500.

@RalfJung
Copy link
Member Author

RalfJung commented Apr 7, 2019

Actually, Miri toolstate should currently be red, some of the run-pass tests ICE with the same error as above. However, due to Manishearth/compiletest-rs#169, that does not make the test suite fail.

I am working on implementing lazy allocation for locals so that we can support unsized locals.

@RalfJung
Copy link
Member Author

RalfJung commented Apr 7, 2019

Uh... @eddyb I think I need your help. I am trying to implement unsized locals in Miri, and some weird stuff is happening. Namely, with the following example program

fn boxed(f: Box<dyn FnOnce() -> i32>) -> i32 {
    f()
}
boxed(Box::new({let x = 13; move || x}))

I am seeing this line of MIR

_0 = const std::ops::FnOnce::call_once(move _3, move _4) -> [return: bb2, unwind: bb4]

where _3: dyn std::ops::FnOnce() -> i32. How does that make any sense?!? Why can we call a trait object method on a non-pointer type?

@bjorn3
Copy link
Member

bjorn3 commented Apr 7, 2019

Why can we call a trait object method on a non-pointer type?

Because of rust-lang/rust#54183 ("Implement by-value object safety")

@RalfJung
Copy link
Member Author

RalfJung commented Apr 7, 2019

I guess that makes sense. Miri doesn't support this nor custom self types.

This will be "fun"...

@RalfJung
Copy link
Member Author

RalfJung commented Apr 7, 2019

That was a good pointer, now at least the caller side works.

However, while the PR you mentioned said something about a shim that should be called, currently it calls the receiver method directly and that does not work very well...

error[E0080]: constant evaluation error: tried to call a function with argument of type [closure@tests/run-pass/closures.rs:52:44: 52:53 x:i32] passing data of type *mut dyn std::ops::FnOnce() -> i32
   --> /home/r/src/rust/rustc.2/src/liballoc/boxed.rs:702:9
    |
702 |         <F as FnOnce<A>>::call_once(*self, args)
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ tried to call a function with argument of type [closure@tests/run-pass/closures.rs:52:44: 52:53 x:i32] passing data of type *mut dyn std::ops::FnOnce() -> i32
    |
note: inside call to `<std::boxed::Box<dyn std::ops::FnOnce() -> i32> as std::ops::FnOnce<()>>::call_once` at tests/run-pass/closures.rs:44:5
   --> tests/run-pass/closures.rs:44:5
    |
44  |     f()
    |     ^^^

@RalfJung RalfJung added A-interpreter Area: affects the core interpreter C-bug Category: This is a bug. labels Apr 7, 2019
@RalfJung
Copy link
Member Author

RalfJung commented Apr 7, 2019

All right, the PR is up at rust-lang/rust#59780 :)

@RalfJung
Copy link
Member Author

Fixed by rust-lang/rust#59780

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-interpreter Area: affects the core interpreter C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

2 participants