Stream: t-compiler/help

Topic: rustc has overflowed its stack


Santiago Pastorino (Aug 09 2019 at 19:01, on Zulip):

Hey, I'm working on a PR https://github.com/rust-lang/rust/pull/63420

Santiago Pastorino (Aug 09 2019 at 19:01, on Zulip):

and I'm getting this error ...

Santiago Pastorino (Aug 09 2019 at 19:01, on Zulip):
thread 'rustc' has overflowed its stack
fatal runtime error: stack overflow
error: Could not compile `core`.

Caused by:
  process didn't exit successfully: `/home/santiago/src/oss/rust1/build/bootstrap/debug/rustc --edition=2018 --crate-name core src/libcore/lib.rs --color always --error-format json --crate-type lib --emit=dep-info,metadata,link -C opt-level=2 -C metadata=027b61dfb739cfed -C extra-filename=-027b61dfb739cfed --out-dir /home/santiago/src/oss/rust1/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -C incremental=/home/santiago/src/oss/rust1/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/incremental -L dependency=/home/santiago/src/oss/rust1/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps -L dependency=/home/santiago/src/oss/rust1/build/x86_64-unknown-linux-gnu/stage1-std/release/deps` (signal: 6, SIGABRT: process abort signal)
command did not execute successfully: "/home/santiago/src/oss/rust1/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/home/santiago/src/oss/rust1/src/libstd/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
failed to run: /home/santiago/src/oss/rust1/build/bootstrap/debug/bootstrap build -i --stage 1 -j 4 src/libstd
Santiago Pastorino (Aug 09 2019 at 19:02, on Zulip):

any pointer on how to see where the error is happening? I mean, other than checking where I'm screwing things up on the code

Santiago Pastorino (Aug 09 2019 at 19:03, on Zulip):

hmm I guess maybe checking the log to see where may be an infinite recursion or something like that?

Santiago Pastorino (Aug 09 2019 at 19:03, on Zulip):

for now I'm going to re-read the code but if someone has any trick to debug this would be appreciated

simulacrum (Aug 09 2019 at 19:04, on Zulip):

@Santiago Pastorino you should be able to get a core dump

simulacrum (Aug 09 2019 at 19:04, on Zulip):

might need ulimit -c unlimited prior to calling rustc

simulacrum (Aug 09 2019 at 19:04, on Zulip):

and then gdb ..../path/to/rustc core

Santiago Pastorino (Aug 09 2019 at 19:22, on Zulip):

@simulacrum hey, let me see

simulacrum (Aug 09 2019 at 19:22, on Zulip):

if the core file bit succeeds you should get a "core dumped" or something like that in the output

simulacrum (Aug 09 2019 at 19:22, on Zulip):

it might get dumped to some odd directory though, I've not had to deal with rustc doing so in a while

Santiago Pastorino (Aug 09 2019 at 19:23, on Zulip):

I guess should be something like

simulacrum (Aug 09 2019 at 19:23, on Zulip):

so perhaps find . -type f -name core will be warranted, presuming your distro also doesn't eat it (e.g., IIRC ubuntu by default has some apport logic to hide core dumps from you)

Santiago Pastorino (Aug 09 2019 at 19:23, on Zulip):

gdb "./x.py build blah blah" core ?

simulacrum (Aug 09 2019 at 19:24, on Zulip):

ah, no, gdb build/x86.../stageN/bin/rustc core

simulacrum (Aug 09 2019 at 19:24, on Zulip):

gdb loosely wants the executable that caused the coredump

Santiago Pastorino (Aug 09 2019 at 19:25, on Zulip):

ahh yeah right

nagisa (Aug 09 2019 at 19:25, on Zulip):

the coredump contains the executable and arguments tha tproduced the core

Santiago Pastorino (Aug 09 2019 at 19:25, on Zulip):

but the core dump is not being generated

Santiago Pastorino (Aug 09 2019 at 19:25, on Zulip):

the coredump contains the executable and arguments tha tproduced the core

yeah yeah, I know that, I wasn't remembering how to generate it

nagisa (Aug 09 2019 at 19:25, on Zulip):

so you can just run gdb coredump and gdb will load the executable itself

Santiago Pastorino (Aug 09 2019 at 19:26, on Zulip):

I guess you meant that the file should be generated, right?

nagisa (Aug 09 2019 at 19:26, on Zulip):

I think you won’t get coredump here because rustc panics it

Santiago Pastorino (Aug 09 2019 at 19:26, on Zulip):

I can't find it

Santiago Pastorino (Aug 09 2019 at 19:26, on Zulip):

I think you won’t get coredump here because rustc panics it

makes sense

Santiago Pastorino (Aug 09 2019 at 19:26, on Zulip):

then? any other option? :)

nagisa (Aug 09 2019 at 19:26, on Zulip):

I think your best bet is to run the rustc command that failed under gdb directly and catch rust_panic or whatever that function is called that we have exactly for breaking on panics.

nagisa (Aug 09 2019 at 19:27, on Zulip):

but you will need to setup envvars that x.py sets up

Santiago Pastorino (Aug 09 2019 at 19:27, on Zulip):

:+1:

nagisa (Aug 09 2019 at 19:27, on Zulip):

I have no idea what those are. We used to have --on-fail=bash that would spawn bash on such failure with environment set up, but it does not work anymore

Santiago Pastorino (Aug 09 2019 at 19:29, on Zulip):

will try out later, thanks

Santiago Pastorino (Aug 09 2019 at 21:41, on Zulip):

was going to try but ...

Santiago Pastorino (Aug 09 2019 at 21:42, on Zulip):

is there a way to see exactly the rustc command with all the env vars that are being used

Santiago Pastorino (Aug 09 2019 at 21:42, on Zulip):

I see this ...

Santiago Pastorino (Aug 09 2019 at 21:42, on Zulip):

/home/santiago/src/oss/rust1/build/bootstrap/debug/rustc --edition=2018 --crate-name core src/libcore/lib.rs --color always --error-format json --crate-type lib --emit=dep-info,metadata,link -C opt-level=2 -C metadata=027b61dfb739cfed -C extra-filename=-027b61dfb739cfed --out-dir /home/santiago/src/oss/rust1/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -C incremental=/home/santiago/src/oss/rust1/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/incremental -L dependency=/home/santiago/src/oss/rust1/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps -L dependency=/home/santiago/src/oss/rust1/build/x86_64-unknown-linux-gnu/stage1-std/release/deps

Santiago Pastorino (Aug 09 2019 at 21:42, on Zulip):

but if I run that I get ...

Santiago Pastorino (Aug 09 2019 at 21:42, on Zulip):
thread 'main' panicked at 'RUSTC_STAGE was not set: NotPresent', src/libcore/result.rs:999:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
Santiago Pastorino (Aug 09 2019 at 21:42, on Zulip):

I can prepend RUSTC_STAGE=1

Santiago Pastorino (Aug 09 2019 at 21:42, on Zulip):

but then ...

Santiago Pastorino (Aug 09 2019 at 21:43, on Zulip):
thread 'main' panicked at 'RUSTC_SYSROOT was not set', src/libcore/option.rs:1034:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
Santiago Pastorino (Aug 09 2019 at 21:43, on Zulip):

is there a way to see everything?

Santiago Pastorino (Aug 09 2019 at 21:43, on Zulip):

included env vars

Santiago Pastorino (Aug 09 2019 at 21:49, on Zulip):

@nagisa :point_up:

nagisa (Aug 09 2019 at 21:49, on Zulip):

probably not easily

Santiago Pastorino (Aug 09 2019 at 21:50, on Zulip):

I think it may be easier to just read the code and figure out what the problem is :P

Last update: Nov 11 2019 at 22:15UTC