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

ICE 'allocation missing in dead_alloc_map' in rustc_mir::interpret when compiling Servo #55223

Closed
SimonSapin opened this issue Oct 20, 2018 · 12 comments
Labels
A-const-eval Area: Constant evaluation (MIR interpretation) A-NLL Area: Non-lexical lifetimes (NLL) I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness NLL-complete Working towards the "valid code works" goal P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly.

Comments

@SimonSapin
Copy link
Contributor

thread 'main' panicked at 'allocation missing in dead_alloc_map', libcore/option.rs:1008: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:480
   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::option::expect_failed
             at libcore/option.rs:1008
  10: <rustc_mir::interpret::memory::Memory<'a, 'mir, 'tcx, M>>::check_align
  11: rustc_mir::interpret::validity::<impl rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, M>>::validate_primitive_type
  12: rustc_mir::interpret::validity::<impl rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, M>>::validate_operand
  13: rustc_mir::interpret::validity::<impl rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, M>>::validate_operand
  14: rustc_mir::interpret::validity::<impl rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, M>>::validate_operand
  15: rustc_lint::builtin::check_const
  16: <rustc_lint::register_builtins::BuiltinCombinedLateLintPass as rustc::lint::LateLintPass<'a, 'tcx>>::check_item
  17: <rustc::lint::context::LateContext<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_item
  18: <rustc::lint::context::LateContext<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_mod
  19: rustc::hir::intravisit::walk_item
  20: <rustc::lint::context::LateContext<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_item
  21: <rustc::lint::context::LateContext<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_mod
  22: rustc::hir::intravisit::walk_item
  23: <rustc::lint::context::LateContext<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_item
  24: <rustc::lint::context::LateContext<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_mod
  25: rustc::hir::intravisit::walk_item
  26: <rustc::lint::context::LateContext<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_item
  27: <rustc::lint::context::LateContext<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_mod
  28: rustc::hir::intravisit::walk_item
  29: <rustc::lint::context::LateContext<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_item
  30: <rustc::lint::context::LateContext<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_mod
  31: rustc::hir::intravisit::walk_crate
  32: rustc::lint::context::check_crate
  33: rustc::util::common::time
  34: rustc::ty::context::tls::enter_context
  35: <std::thread::local::LocalKey<T>>::with
  36: rustc::ty::context::TyCtxt::create_and_enter
  37: rustc_driver::driver::compile_input
  38: rustc_driver::run_compiler_with_pool
  39: rustc_driver::driver::spawn_thread_pool
  40: rustc_driver::run_compiler
  41: <scoped_tls::ScopedKey<T>>::set
  42: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  43: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  44: rustc_driver::run
  45: rustc_driver::main
  46: std::rt::lang_start::{{closure}}
  47: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  48: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  49: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  50: main
  51: __libc_start_main
  52: <unknown>
query stack during panic:
end of query stack

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.31.0-nightly (78ff609d7 2018-10-19) running on x86_64-unknown-linux-gnu

note: compiler flags: -C debuginfo=2 -C link-args=-fuse-ld=gold --crate-type lib

note: some of the compiler flags provided by cargo are hidden

�[0m�[0m�[1m�[31merror:[0m Could not compile `script`.
@SimonSapin
Copy link
Contributor Author

SimonSapin commented Oct 22, 2018

Commit range: e7f5d48...78ff609. Merged PRs:

@oli-obk oli-obk added the A-const-eval Area: Constant evaluation (MIR interpretation) label Oct 22, 2018
@oli-obk
Copy link
Contributor

oli-obk commented Oct 22, 2018

I honestly don't know what your code does, but from the error message and the backtrace I was able to create

#![feature(const_let)]

union Foo<'a> {
    y: &'a (),
    long_live_the_unit: &'static (),
}

const FOO: &() = {
    let y = ();
    unsafe { Foo { y: &y }.long_live_the_unit }
};

fn main() {
}

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=b23ea8c8d50f4a31a52780e27ef55fa5

@jdm jdm added the I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ label Oct 22, 2018
@oli-obk
Copy link
Contributor

oli-obk commented Oct 22, 2018

@oli-obk oli-obk added regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness A-NLL Area: Non-lexical lifetimes (NLL) labels Oct 22, 2018
@oli-obk
Copy link
Contributor

oli-obk commented Oct 22, 2018

cc @nikomatsakis @pnkfelix I think (haven't bisected yet) that #55152 is the likelyest candidate to have regressed the following (previously successfully compiling code example):

struct Slice(&'static [&'static [u8]]);
static MAP: Slice = Slice(&[
    b"CloseEvent" as &'static [u8],
]);

the following warning will keep the code compiling but cause dangling safe references in downstream code

warning[E0716]: temporary value dropped while borrowed
  --> $DIR/dangling-alloc-id-ice-2.rs:5:28
   |
LL |    static MAP: Slice = Slice(&[
   |   ___________________________-^
   |  |___________________________|
   | ||
LL | ||     b"CloseEvent" as &'static [u8],
LL | || ]);
   | || -- temporary value is freed at the end of this statement
   | ||_|
   | |__creates a temporary which is freed while still in use
   |    cast requires that borrow lasts for `'static`
   |
   = warning: This error has been downgraded to a warning for backwards compatibility with previous releases.
           It represents potential unsoundness in your code.
           This warning will become a hard error in the future.

@pnkfelix
Copy link
Member

pnkfelix commented Oct 23, 2018

"dangling safe references" ? Oh, you must mean "dangling &-references" ? Sorry, wasn't sure if the word "safe" there was meant to mean "this code is fine and should be accepted by the compiler.

@pnkfelix
Copy link
Member

Do we not guarantee that an expression like [ b"CloseEvent" as &'static [u8], ] can be promoted to a static value?

@pnkfelix
Copy link
Member

in particular, the code seems to work fine if I replace [ b"CloseEvent" as &'static [u8], ] with just [ b"CloseEvent", ]

@pnkfelix pnkfelix added the NLL-complete Working towards the "valid code works" goal label Oct 23, 2018
@pnkfelix
Copy link
Member

(We probably should fork off separate issues to track the distinct problems that @oli-obk has uncovered here...)

@nikomatsakis
Copy link
Contributor

cc @eddyb -- this is related to the drop of temporaries in static

@nikomatsakis
Copy link
Contributor

Er, never mind, my bad. The bug here is that promotion is not happening due to the cast, which is something that @oli-obk and I discussed on the PR -- it's a result presumably of needing to "loosen" the promotion rules to permit user type ascriptions.

@oli-obk
Copy link
Contributor

oli-obk commented Oct 23, 2018

In #55152 we were talking about const propagation, not const promotion ;)

I have no idea why your PR would break promotion in this case. I checked the const promotion code, and we're already treating type ascription as a nop.

bors-servo pushed a commit to servo/servo that referenced this issue Oct 23, 2018
Add a workaround for a rustc ICE

While rust-lang/rust#55223 is being fixed, this workaround will allow servo to compile on the latest nightly rustc

r? @SimonSapin

---

- [ ] `./mach build -d` does not report any errors
  * I'm getting
  ```
    Collecting voluptuous==0.10.5 (from -r /home/oliver/Projects/rust/servo/python/requirements.txt (line 18))
      Using cached https://files.pythonhosted.org/packages/c3/81/c84f8a3e723b760fdd1c41fc80201cb80cd29c1bce5159d8918c58df7d2a/voluptuous-0.10.5.tar.gz
        Complete output from command python setup.py egg_info:
        Traceback (most recent call last):
          File "<string>", line 1, in <module>
          File "/tmp/pip-install-Qdty2x/voluptuous/setup.py", line 16, in <module>
            f.write(long_description)
        UnicodeEncodeError: 'ascii' codec can't encode character u'\u2019' in position 1229: ordinal not in range(128)
    ```
    locally, no clue how to continue from there. The script crate compiles fine with `cargo build`
- [ ] `./mach test-tidy` does not report any errors

- [X] These changes do not require tests because the `script` crate just won't compile without this change

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/22000)
<!-- Reviewable:end -->
pietroalbini added a commit to pietroalbini/rust that referenced this issue Oct 23, 2018
kennytm added a commit to kennytm/rust that referenced this issue Oct 25, 2018
@pnkfelix pnkfelix added the P-high High priority label Oct 25, 2018
@oli-obk oli-obk closed this as completed Oct 25, 2018
@pnkfelix
Copy link
Member

closing as duplicate of #55288, which is where the bulk of the remaining work is

kennytm added a commit to kennytm/rust that referenced this issue Oct 26, 2018
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Oct 27, 2018
bors added a commit that referenced this issue Nov 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-eval Area: Constant evaluation (MIR interpretation) A-NLL Area: Non-lexical lifetimes (NLL) I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness NLL-complete Working towards the "valid code works" goal P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly.
Projects
None yet
Development

No branches or pull requests

5 participants