Closed
Description
Firstly, I have been unable to reproduce this minimally, but it should be similar to something like this, but this example gives the correct error. I'll update this issue if I can find a proper repro.
However, locally I'm getting an ICE:
error: internal compiler error: Accessing `(*_5)` with the kind `Write(Move)` shouldn't be possible
--> src/madt.rs:40:31
|
40 | let header = unsafe { *(pointer as *const EntryHeader) };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: (MoveData { move_paths: [Mov
ePath { place: _0 }, MovePath { place: _1 }, MovePath { place: _2 }, MovePath { place: _3 }, MovePat
h { place: _4 }, MovePath { place: _5 }, MovePath { place: _6 }, MovePath { place: _7 }, MovePath {
place: _8 }, MovePath { place: _9 }, MovePath { place: _10 }, MovePath { place: _11 }, MovePath { pl
ace: _12 }], moves: [mp6@bb0[6], mp6@bb0[7], mp5@bb0[9], mp9@bb0[15]], loc_map: LocationMap { map: [
[[], [], [], [], [], [], [mo0], [mo1], [], [mo2], [], [], [], [], [], [mo3]]] }, path_map: [[], [],
[], [], [], [mo2], [mo0, mo1], [], [], [mo3], [], [], []], rev_lookup: MovePathLookup { locals: [mp0
, mp1, mp2, mp3, mp4, mp5, mp6, mp7, mp8, mp9, mp10, mp11, mp12], projections: {} }, inits: [mp1@src
/madt.rs:38:13: 38:22 (Deep), mp3@src/madt.rs:39:23: 39:46 (Deep), mp6@src/madt.rs:40:33: 40:40 (Dee
p), mp5@src/madt.rs:40:32: 40:63 (Deep), mp4@src/madt.rs:40:31: 40:63 (Deep), mp12@<panic macros>:4:
1: 4:72 (Deep), mp10@<panic macros>:4:1: 4:72 (Deep), mp9@<panic macros>:4:1: 4:72 (Deep)], init_loc
_map: LocationMap { map: [[[], [in1], [], [], [], [in2], [in3], [], [in4], [], [], [], [in5], [in6],
[in7], []]] }, init_path_map: [[], [in0], [], [in1], [in4], [in3], [in2], [], [], [in7], [in6], [],
[in5]] }, [IllegalMove { cannot_move_out_of: IllegalMoveOrigin { location: bb0[8], kind: BorrowedCo
ntent { target_ty: madt::EntryHeader } } }])', libcore/result.rs:945:5
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:71
at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:211
3: std::panicking::default_hook
at libstd/panicking.rs:227
4: rustc::util::common::panic_hook
5: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:479
6: std::panicking::continue_panic_fmt
at libstd/panicking.rs:390
7: rust_begin_unwind
at libstd/panicking.rs:325
8: core::panicking::panic_fmt
at libcore/panicking.rs:77
9: core::result::unwrap_failed
10: <rustc_mir::transform::elaborate_drops::ElaborateDrops as rustc_mir::transform::MirPass>::run_
pass
11: rustc_mir::transform::optimized_mir::{{closure}}
12: rustc_mir::transform::optimized_mir
13: rustc::ty::query::__query_compute::optimized_mir
14: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::q
ueries::optimized_mir<'tcx>>::compute
15: rustc::ty::context::tls::with_context
16: rustc::dep_graph::graph::DepGraph::with_task_impl
17: rustc::ty::context::tls::with_related_context
18: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_wit
h_job
19: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::try_get_query
20: rustc::ty::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::instance_mir
21: rustc_mir::monomorphize::collector::collect_items_rec
22: rustc_mir::monomorphize::collector::collect_crate_mono_items::{{closure}}
23: rustc::util::common::time
24: rustc_mir::monomorphize::collector::collect_crate_mono_items
25: rustc::util::common::time
26: rustc_codegen_llvm::base::collect_and_partition_mono_items
27: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::q
ueries::collect_and_partition_mono_items<'tcx>>::compute
28: rustc::ty::context::tls::with_context
29: rustc::dep_graph::graph::DepGraph::with_task_impl
30: rustc::ty::context::tls::with_related_context
31: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_wit
h_job
32: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query
33: rustc::ty::query::plumbing::force_from_dep_node
34: rustc::dep_graph::graph::DepGraph::try_mark_green
35: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::try_mark_green_
and_read
36: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
37: rustc_metadata::encoder::encode_metadata
38: rustc_metadata::cstore_impl::<impl rustc::middle::cstore::CrateStore for rustc_metadata::cstor
e::CStore>::encode_metadata
39: rustc::ty::context::TyCtxt::encode_metadata
40: rustc_codegen_llvm::base::write_metadata
41: rustc::util::common::time
42: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBacken
d>::codegen_crate
43: rustc::util::common::time
44: rustc_driver::driver::phase_4_codegen
45: rustc_driver::driver::compile_input::{{closure}}
46: rustc::ty::context::tls::enter_context
47: <std::thread::local::LocalKey<T>>::with
48: rustc::ty::context::TyCtxt::create_and_enter
49: rustc_driver::driver::compile_input
50: rustc_driver::run_compiler_with_pool
51: <scoped_tls::ScopedKey<T>>::set
52: <scoped_tls::ScopedKey<T>>::set
53: syntax::with_globals
54: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
55: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:105
56: rustc_driver::run
57: rustc_driver::main
58: std::rt::lang_start::{{closure}}
59: std::panicking::try::do_call
at libstd/rt.rs:59
at libstd/panicking.rs:310
60: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:105
61: std::rt::lang_start_internal
at libstd/panicking.rs:289
at libstd/panic.rs:392
at libstd/rt.rs:58
62: main
63: __libc_start_main
64: <unknown>
query stack during panic:
#0 [optimized_mir] processing `<madt::MadtEntryIter<'a> as core::iter::Iterator>::next`
#1 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack
error: aborting due to previous error
error: internal compiler error: unexpected panic
This is with rustc 1.29.0-nightly (e5f6498d3 2018-07-10).
Metadata
Metadata
Assignees
Labels
Blocker: Implemented in the nightly compiler and unstable.Category: This is a bug.Call for participation: An issue has been fixed and does not reproduce, but no test has been added.Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Low priorityRelevant to the compiler team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
hellow554 commentedon Jul 12, 2018
Your example does not panic on the playground (which uses the given nightly compiler) 😮
IsaacWoods commentedon Jul 12, 2018
@hellow554 yup, am aware and I'm trying to find a minimal example that does (it does locally even after a
cargo clean). There's clearly some subtlety in the actual code causing it to ICEestebank commentedon May 8, 2019
@IsaacWoods do you still have the original trigger for this error? If so, could you let us know if the problem still persists?
IsaacWoods commentedon May 8, 2019
@estebank I do not have the full crate to test easily, but a better testcase adapted slightly from the actual code passes on the latest nightly (gives the correct error), so I don't think this persists.
ghost commentedon Sep 30, 2019
I have one with:
Source code here: https://github.com/howaboutsynergy/memdb/tree/write_move_shouldnt_be_possible
just run
./gooutput:
with backtrace
^ yes it's stuck there, not sure why! I will C-c after a while, been a few minutes. It's probably cargo's doing?
ghost commentedon Sep 30, 2019
here's a simplified version but beware that it doesn't show the ICE on playground:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=666c4fdb2df458f87edce89277024726
ICE shown only locally,
or could it be that my (locally built)"nightly" is too old now (couple of days) and this ICE is gone? or more likely playground strips ICE from output?It just needs-Z treat-err-as-bug=500ghost commentedon Sep 30, 2019
the better testcase mentioned above also ICEs only locally, and the ICE cannot be seen on playground.
hellow554 commentedon Oct 1, 2019
@howaboutsynergy your compiler looks incorrect to me, or am I missing something?
vs
ghost commentedon Oct 1, 2019
@hellow554 yeah, I've compiled rust locally, but here's with current latest nightly:
that's running the example from this comment above.
hellow554 commentedon Oct 1, 2019
It is only happening because of the compiler option
-Z treat-err-as-bug. Not sure what it is, or why you have it enabled :) But yeah, I can provoke an ICE with it.ghost commentedon Oct 1, 2019
that's odd, I have it in
.cargo/configasbut I'd think it only triggers if at least 5 errors were encountered, not just 1.
even works with
"-Z", "treat-err-as-bug=500"heh.Nice catch!
as to why I have it: #27189 (comment)
16 remaining items