Stream: t-compiler

Topic: rustc panic


blitzerr (Dec 29 2018 at 01:07, on Zulip):
thread 'rustc' panicked at 'no entry found for key', src/libcore/option.rs:1040:5ore
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

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.33.0-dev running on x86_64-apple-darwin

note: compiler flags: -Z osx-rpath-install-name -Z force-unstable-if-unmarked -C opt-level=2 -C prefer-dynamic -C debug-assertions=y -C codegen-units=12 -C link-args=-Wl,-rpath,@loader_path/../lib --crate-type lib

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

error: Could not compile `core`.

To learn more, run the command again with --verbose.
command did not execute successfully: "rust/build/x86_64-apple-darwin/stage0/bin/cargo" "build" "--target" "x86_64-apple-darwin" "-j" "12" "--release" "--features" "panic-unwind backtrace" "--manifest-path" "rust/src/libstd/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
failed to run: rust/build/bootstrap/debug/bootstrap build --stage 1 src/libstd
Build completed unsuccessfully in 0:13:26
nagisa (Dec 29 2018 at 01:25, on Zulip):

Do report ICEs to the issue tracker, not here.

nagisa (Dec 29 2018 at 01:26, on Zulip):

Especially if it is reproducible and happens on a clean checkout (to remove the possibility of your own change of some sort causing it)

blitzerr (Dec 29 2018 at 05:24, on Zulip):

@nagisa
If my code is causing the compiler to panic, how do I get the stack trace or something to get the location ?

nagisa (Dec 29 2018 at 11:47, on Zulip):

RUST_BACKTRACE=1 gives backtraces as usual.

blitzerr (Dec 29 2018 at 16:51, on Zulip):

@nagisa Apparently it does not give you backtrace on mac as said here. I am wondering if there is a way of getting print statements while building the compiler as the panic in my case happens during building rustc. This deals with debug statements while compiling a file with a built compiler and not during the build.

Zoxc (Dec 29 2018 at 16:52, on Zulip):

You can use eprintln! in the compiler

blitzerr (Dec 29 2018 at 16:59, on Zulip):

Thanks a lot @Zoxc . Let me try that

Esteban Küber (Dec 31 2018 at 19:32, on Zulip):

@blitzerr I believe that documentation is incorrect, I get backtraces for both my own code and rustc in mac 10.13

blitzerr (Dec 31 2018 at 19:39, on Zulip):

In my case, I just got a line about the point of panic but not the entire call stack.

thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', /Users/blitz/rustc-dev/rust/src/libcore/slice/mod.rs:2455

Do you get the full stack ?

blitzerr (Dec 31 2018 at 19:40, on Zulip):

@Esteban Küber

nagisa (Dec 31 2018 at 19:48, on Zulip):

@blitzerr are you on a less standard platform, perhaps?

Esteban Küber (Dec 31 2018 at 20:01, on Zulip):

I do

Esteban Küber (Dec 31 2018 at 20:02, on Zulip):
$ RUST_BACKTRACE=full ./stage1/bin/rustc ../../src/test/ui/issues/issue-44023.rs -Ztreat-err-as-bug
error[E0308]: mismatched types
 --> ../../src/test/ui/issues/issue-44023.rs:5:42
  |
5 |   fn საჭმელად_გემრიელი_სადილი ( ) -> isize { //~ ERROR mismatched types
  |  __________________________________________^
6 | | }
  | |_^ expected isize, found ()
  |
  = note: expected type `isize`
             found type `()`

thread 'rustc' panicked at 'encountered error with `-Z treat_err_as_bug', src/librustc_errors/lib.rs:490:13
stack backtrace:
   0:        0x10fe5521f - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::hc6fe37d6df1f3fe5
   1:        0x10fe7f3cd - std::sys_common::backtrace::print::hb7f980371c0868d5
   2:        0x10fe76aa1 - std::panicking::default_hook::{{closure}}::h8241ef64100dd6cc
   3:        0x10fe76830 - std::panicking::default_hook::h60d1f8576b12717c
   4:        0x10d715921 - rustc::util::common::panic_hook::h69f8586f8a0f0325
   5:        0x10fe771d1 - std::panicking::rust_panic_with_hook::h3ddb1c46e6feced8
   6:        0x10f766cb4 - std::panicking::begin_panic::hc0718cb54d8ba326
   7:        0x10f7528c6 - rustc_errors::Handler::emit_db::h71b6a584809709bb
   8:        0x10f75f1cc - rustc_errors::diagnostic_builder::DiagnosticBuilder::emit::h7d0ef8ff5a1046cd
   9:        0x10ba1ba5c - <rustc_typeck::check::coercion::CoerceMany<'gcx, 'tcx, 'exprs, E>>::coerce_inner::h4c499b4e1caffb2b
  10:        0x10bb50812 - rustc_typeck::check::FnCtxt::with_breakable_ctxt::ha4cc4bc83fcb08c3
  11:        0x10bb8fbe4 - rustc_typeck::check::FnCtxt::check_block_with_expected::hb13f83d0c4498f69
  12:        0x10bb81a40 - rustc_typeck::check::FnCtxt::check_expr_kind::h75e62a260248dbeb
  13:        0x10bb814e4 - rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs::hbe73d170359aeba1
  14:        0x10bb806ac - rustc_typeck::check::FnCtxt::check_return_expr::h2629ed759b193b8d
  15:        0x10bb7155d - rustc_typeck::check::check_fn::h200e74f0e5e3c2cb
  16:        0x10b9de428 - rustc::ty::context::GlobalCtxt::enter_local::hf6ba87dbedd33942
  17:        0x10bb70155 - rustc_typeck::check::typeck_tables_of::h162f840803ba1fe4
  18:        0x10d7d16fe - rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::typeck_tables_of<'tcx>>::compute::h1aa06c980f0e396c
  19:        0x10db6f73c - rustc::dep_graph::graph::DepGraph::with_task_impl::h4451d90f125a1e9a
  20:        0x10d7c7398 - <rustc::ty::query::plumbing::JobOwner<'a, 'tcx, Q>>::start::he16f56a818977929
  21:        0x10d8e8412 - rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job::h7a6693495921f881
  22:        0x10d89432b - rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::try_get_with::hc580e739dda9bdd3
  23:        0x10d906d6f - rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::ensure_query::h099f19c1d38763ed
  24:        0x10baac45b - rustc::session::Session::track_errors::hf9a6f2a242c90b0b
  25:        0x10bb6fcbf - rustc_typeck::check::typeck_item_bodies::h4534ee4d734144a1
  26:        0x10b942ea6 - rustc::ty::query::__query_compute::typeck_item_bodies::hf568d3995a6c4784
  27:        0x10ba8070b - rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::typeck_item_bodies<'tcx>>::compute::h7b6aface07086eb1
  28:        0x10b95a166 - rustc::dep_graph::graph::DepGraph::with_task_impl::hb1b264e398d9686a
  29:        0x10ba8d101 - <rustc::ty::query::plumbing::JobOwner<'a, 'tcx, Q>>::start::hc63f00cac165842f
  30:        0x10b9b56e9 - rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job::h454b1e98cb985f5e
  31:        0x10b982ff7 - rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::try_get_with::h5572ff8db339f814
  32:        0x10b963997 - rustc::util::common::time::h9f12939f16f76f2b
  33:        0x10bb0a296 - rustc_typeck::check_crate::h842d9672d6af315a
  34:        0x10acc632b - <std::thread::local::LocalKey<T>>::with::h63437dce8de12658
  35:        0x10aca74eb - rustc::ty::context::TyCtxt::create_and_enter::h673adfdda68da1ea
  36:        0x10addaa98 - rustc_driver::driver::phase_3_run_analysis_passes::h67cf81730cc3ec14
  37:        0x10ada44a5 - rustc_driver::driver::compile_input::ha5fcb3f0c8f48e47
  38:        0x10ad06f4e - rustc_driver::run_compiler_with_pool::haa8beec656c50be8
  39:        0x10acb287e - <scoped_tls::ScopedKey<T>>::set::hd44e699e53d15e75
  40:        0x10ad05eb8 - rustc_driver::run_compiler::hc40f67821fa523f1
  41:        0x10acb23cb - <scoped_tls::ScopedKey<T>>::set::hc5ff8cbf82c6994c
  42:        0x10ac8239d - syntax::with_globals::hf12d7f48e28fa87c
  43:        0x10fe868fe - __rust_maybe_catch_panic
  44:        0x10addc49d - <F as alloc::boxed::FnBox<A>>::call_box::h1a1055a3d353ec75
  45:        0x10fe5f8f7 - std::sys_common::thread::start_thread::h0f67f5321d68e7d5
  46:        0x10fe6a738 - std::sys::unix::thread::Thread::new::thread_start::h1398251991321fad
  47:     0x7fff57254660 - _pthread_body
  48:     0x7fff5725450c - _pthread_start
query stack during panic:
#0 [typeck_tables_of] processing `საჭმელად_გემრიელი_სადილი`
#1 [typeck_item_bodies] type-checking all item bodies
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.33.0-dev running on x86_64-apple-darwin

note: compiler flags: -Z treat-err-as-bug
blitzerr (Dec 31 2018 at 20:03, on Zulip):

Interesting.

Esteban Küber (Dec 31 2018 at 20:03, on Zulip):

config.toml has this:

# =============================================================================
# Options for compiling Rust code itself
# =============================================================================
[rust]

# Indicates that the build should be optimized for debugging Rust. Note that
# this is typically not what you want as it takes an incredibly large amount of
# time to have a debug-mode rustc compile any code (notably libstd). If this
# value is set to `true` it will affect a number of configuration options below
# as well, if unconfigured.
debug = false

# Whether or not to optimize the compiler and standard library
# Note: the slowness of the non optimized compiler compiling itself usually
#       outweighs the time gains in not doing optimizations, therefore a
#       full bootstrap takes much more time with optimize set to false.
#optimize = true

# Number of codegen units to use for each compiler invocation. A value of 0
# means "the number of cores on this machine", and 1+ is passed through to the
# compiler.
codegen-units = 0

# Whether or not debug assertions are enabled for the compiler and standard
# library. Also enables compilation of debug! and trace! logging macros.
debug-assertions = false

# Whether or not debuginfo is emitted
#debuginfo = true

# Whether or not line number debug information is emitted
debuginfo-lines = true
Esteban Küber (Dec 31 2018 at 20:03, on Zulip):

Note last line

Esteban Küber (Dec 31 2018 at 20:03, on Zulip):

that might be it

blitzerr (Dec 31 2018 at 20:04, on Zulip):

@nagisa
I use the macOs Mojave as my Rustc development platform.

blitzerr (Dec 31 2018 at 20:05, on Zulip):

Let me double check my config.toml

nagisa (Dec 31 2018 at 20:15, on Zulip):

Then there should be some backtrace output with that environment variable set, even it it does not contain filenames/etc

nagisa (Dec 31 2018 at 20:15, on Zulip):

As long as you’re on x86{,_64}.

nagisa (Dec 31 2018 at 20:15, on Zulip):

libbacktrace may not support other architectures well/at all.

blitzerr (Dec 31 2018 at 21:10, on Zulip):

debuginfo-lines is set to true in my case :frown:

blitzerr (Dec 31 2018 at 21:12, on Zulip):
# Whether or not `panic!`s generate backtraces (RUST_BACKTRACE)
 #backtrace = true

How about that line ? Its commented out in my case

blitzerr (Dec 31 2018 at 21:14, on Zulip):

@nagisa
Before RUST_BACKTRACE=1, it would give me nothing but after setting it, I got some info
thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', /Users/blitz/rustc-dev/rust/src/libcore/slice/mod.rs:2455

Though not the entire call stack as @Esteban Küber gets.

blitzerr (Dec 31 2018 at 21:16, on Zulip):
diff config.toml config.toml.example
22c22
< optimize = false
---
> #optimize = true
31c31
< release-debuginfo = true
---
> #release-debuginfo = false
34c34
< assertions = true
---
> #assertions = false
278c278
< codegen-units = 0
---
> #codegen-units = 1
286c286
< debug-assertions = true
---
> #debug-assertions = false
289c289
< debuginfo = true
---
> #debuginfo = false
292c292
< debuginfo-lines = true
---
> #debuginfo-lines = false
401c401,406
< jemalloc = false
---
> #jemalloc = false
>
> # Run tests in various test suites with the "nll compare mode" in addition to
> # running the tests in normal mode. Largely only used on CI and during local
> # development of NLL
> #test-compare-mode = false
blitzerr (Jan 02 2019 at 21:08, on Zulip):

@nikomatsakis
This is the panic I was referring to

nikomatsakis (Jan 02 2019 at 21:28, on Zulip):

btw if you are having trouble with RUST_BACKTRACE for some reason, @blitzerr, you might try using lldb to get a backtrace

blitzerr (Jan 02 2019 at 22:30, on Zulip):

Do you mean, building the compiler from inside lldb so it breaks into lldb when it hits the panic ?

nikomatsakis (Jan 02 2019 at 22:37, on Zulip):

yes but it's all much more painful when it dies during bootstrapping

nikomatsakis (Jan 02 2019 at 22:38, on Zulip):

we used to have a nice tool for that but it stopped working for me at least

blitzerr (Jan 03 2019 at 04:55, on Zulip):

@nikomatsakis
How do you invoke x.py from within the lldb ?

pnkfelix (Jan 29 2019 at 11:43, on Zulip):

I wouldn't invoke x.py from within lldb. I would use x.py build with ... I think --verbose ... to observe the actual command line invocation of rustc, and then use that command line with lldb. ... Except my memory is that this workflow is often foiled by x.py setting environment variables that you'll need to replicate yourself.

blitzerr (Jan 31 2019 at 14:33, on Zulip):

Thanks @pnkfelix

pnkfelix (Jan 31 2019 at 14:34, on Zulip):

There's a couple ways to work around the above problem

pnkfelix (Jan 31 2019 at 14:34, on Zulip):

one of the most direct hacks is to just find out what the environment settings are, by making the rustc invocation run env first to print that out

pnkfelix (Jan 31 2019 at 14:35, on Zulip):

I can't remember if the best way to do this is to override the RUSTC environment variable before invoking x.py, or if there's a better approach.

Last update: Nov 16 2019 at 02:10UTC