Skip to content
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

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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