Stream: t-compiler/help

Topic: changes to backtraces


davidtwco (Dec 25 2019 at 00:09, on Zulip):

Have there been changes to backtraces recently? I think I've got my config.toml right and I've rebuilt everything once or twice but my stack traces (of a ICE I've caused in libcore locally) don't have any of the compiler in them?

davidtwco (Dec 25 2019 at 00:51, on Zulip):

(you can find my config.toml here)

davidtwco (Dec 25 2019 at 01:57, on Zulip):

Nuking the build directory entirely hasn't helped, still only getting this backtrace:

error: internal compiler error: src/librustc/traits/codegen/mod.rs:58: Encountered error `Unimplemented` selecting `Binder(<T as num::dec2flt::rawfp::RawFloat>)` during codegen

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:895:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /home/david/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /home/david/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:77
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1057
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:195
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:215
error: could not compile `core`.

(contents of the error aren't relevant, just the emptiness of the backtrace, this is during building the stage 1 std artifacts)

oli (Dec 25 2019 at 02:01, on Zulip):

I've never used the config.toml backtrace option, what happens if you also specifiy RUST_BACKTRACE=1 or RUST_BACKTRACE=full?

oli (Dec 25 2019 at 02:02, on Zulip):

also: maybe there's a double panic happening?

simulacrum (Dec 25 2019 at 02:02, on Zulip):

I would also try w/o the RUST_BACKTRACE env and paste that output

simulacrum (Dec 25 2019 at 02:03, on Zulip):

(sometimes the panic backtracing will hide the second backtrace I think)

davidtwco (Dec 25 2019 at 02:12, on Zulip):

I was using RUST_BACKTRACE=1, will try without tomorrow (it’s 2am here), thanks.

simulacrum (Dec 25 2019 at 02:13, on Zulip):

(it sounds like a bug though -- we haven't actually changed anything here recently though to my knowledge)

davidtwco (Dec 25 2019 at 10:00, on Zulip):

Omitting RUST_BACKTRACE=1 shows no backtraces. I've recently switched to fish, I wonder if it could be something related to that? Perhaps the cargo invocation is getting the variable but when it runs rustc that isn't?

davidtwco (Dec 25 2019 at 10:28, on Zulip):

No luck with RUST_BACKTRACE=full or commenting the backtrace option in config.toml.

davidtwco (Dec 25 2019 at 10:28, on Zulip):

(or with changing how I'm setting the environment variable)

oli (Dec 25 2019 at 11:41, on Zulip):

:confused:

oli (Dec 25 2019 at 11:42, on Zulip):

if you remove the backtrace option you are still getting backtraces but truncated?

oli (Dec 25 2019 at 11:42, on Zulip):

at this point I can only recommend running with --verbose, getting the raw invocation, and running that in gdb

oli (Dec 25 2019 at 11:42, on Zulip):

although with --verbose you only get the raw cargo invocation, so you'll need to run that with --verbose so you get the raw rustc invocation

davidtwco (Dec 25 2019 at 12:00, on Zulip):

Yeah, only the truncated backtrace.

davidtwco (Dec 25 2019 at 12:01, on Zulip):

In the past when I’ve tried to run the rustc invocation for libcore, it has depended on environment variables from cargo and so that hasn’t worked.

davidtwco (Dec 25 2019 at 12:01, on Zulip):

That might have changed though, I’ll try.

davidtwco (Dec 25 2019 at 13:49, on Zulip):

Yeah, running the rustc invocation that is printed asks for RUSTC_STAGE, RUSTC_SYSROOT, etc.

davidtwco (Dec 25 2019 at 13:49, on Zulip):

(and the backtrace from that doesn't include the compiler)

davidtwco (Dec 25 2019 at 14:20, on Zulip):

So, running the rustc from ./build/x86_64-unknown-linux-gnu/stage1 (which I'm pretty sure is the compiler I just built, and not the beta compiler - or the wrapper from bootstrap) with the same flags seems to compile correctly? Not sure why it isn't reproducing the error.

davidtwco (Dec 25 2019 at 15:35, on Zulip):

Switched build directory, built an older version of my branch (before my rustfmt rebase) and it had a compiler backtrace, updated and rebuilt, no compiler backtrace. I've not changed anything that would break backtraces between those revisions. I'm able to reproduce the lack of backtrace on master, going to bisect.

davidtwco (Dec 25 2019 at 15:39, on Zulip):

Starting from this commit which was what my branch was based on pre-rebase.

davidtwco (Dec 25 2019 at 18:36, on Zulip):

Results from the bisect - http://sprunge.us/ACXOa3

davidtwco (Dec 25 2019 at 18:36, on Zulip):

Looks like a change in LLVM

davidtwco (Dec 25 2019 at 18:36, on Zulip):

Not really sure how to work around that.

davidtwco (Dec 25 2019 at 19:01, on Zulip):

Filed #67615 with what I've found

davidtwco (Dec 27 2019 at 17:47, on Zulip):

For those following along at home, turns out this was because I had debug = true, any debuginfo-level > 1 will cause this.

davidtwco (Dec 27 2019 at 17:48, on Zulip):

Frustratingly it changed the ICE that I had been getting, which means I hadn't actually made any progress. :sad:

davidtwco (Dec 27 2019 at 17:57, on Zulip):

(except it hasn't now that I'm back on my original working directory, :shrug:)

Last update: Apr 05 2020 at 01:45UTC