'rustc' panicked at 'failed to lookup SourceFile in new context'
#70924
Comments
|
Thanks for the report. Can you provide the source code needed to reproduce this? |
|
Sure, the exact code which I was trying to build is now here in this branch: |
jonas-schievink
added
C-bug
|
I got the exact same issue at the moment edit: |
|
I also tested 'cargo clean' - and it also worked for me :) |
|
Do you remember the change that induced this bug? It looks like this is a problem with incremental compilation, so we'll need to find a change that triggers the issue. |
|
@jonas-schievink In the mean time I might also did: |
|
@manio I was more wondering about any changes to your code, not the toolchain. It's fine if you don't remember of course, but it would make it easier to track this bug down. Thanks! |
|
@jonas-schievink |
|
For me it happened after this. Also tried rocket, I set ‘rustup default nightly’ and successfully compiled and ran with ‘cargo run’. But I remembered you could override for single projects. So I did ‘rustup default stable’ and then rustup override set nightly. The when i did ‘cargo run’ it gave the error. |
|
@jonas-schievink If you are unable to fix it without reproducing the problem then I am ok with closing this issue. It's up to you, guys... |
|
I got the exact same issue a moment ago. Cleaning has helped as well. It was happening only for 'cargo test' for me, 'cargo build' was working fine. It happened after adding constructor methods to simple 2 fields struct and changing one test to use them instead of standard struct creation. Unfortunately I cannot share the repo, since it is private. |
Are you by any chance able to reliably reproduce the error, though? |
|
Just tried to go back and forth with my recent changes, but unfortunately I couldn't reproduce the error. |
|
The error popped up for me as well (#71380), for example in the following Travis-CI build: https://travis-ci.org/github/tock/tock/builds/677725676 |
|
Hmm, @gendx I can’t find anything indicating errors behind your ci build link, probably the information updated after a successful rebuild (indicating 37 minutes ago as of now), maybe I just don’t know where to look to get the log with an error. Furthermore, and in risk of repeating myself in this thread, but would you by any change be able to reproduce the panic somehow? Unfortunately, it seems to be a reoccurring theme around this bug that the error is surprisingly hard to reproduce after the |
|
@steffahn indeed, a maintainer re-ran the Travis-CI build in the meantime (tock/tock#1776 (comment)), so it looks like the log is lost (from this link at least). I kept a snapshot of my filesystem in the state which triggered the crash. Although I unfortunately can't share this snapshot of my filesystem, I can reproduce it (see my stack trace in #71380). One may have more luck to reproduce it with Tock, as it triggered already twice today (on my machine and on one of the Travis-CI builds). Note: In the past, Tock already had some issues with a "bad" nightly version causing unexpected errors (although not an ICE) when the build cache was "dirty" (tock/tock#1657). The process to reproduce this was the following. # First, make sure to have a clean repo.
make clean # i.e. cargo clean
# The first run works normally.
make ci-travis # i.e. cargo build/test/etc
# Change a file to trigger a rebuild.
# No need to actually change anything, touching is enough.
touch kernel/src/debug.rs
# The second run triggers warnings/errors about `#[warn(unused_attributes)]`.
make ci-travis # i.e. cargo build/test/etcIn the end we fixed it by upgrading from |
|
If that's of any help besides the stack trace and the source code (tock/tock@0486784), the following Failing `rustc` commands
Caused by: Caused by: target/debug/incremental/
target/debug/deps/
|
I see, one important open question however is: which steps are necessary, from a clean start, to get your target directory into the state that the error can happen? Is one/multiple update(s) of the rust nightly version involved? Do you need to do certain changes to certain code which influence things in incremental compilation? Both? Or are you actually already saying “I can reproduce it” as in: you can reproduce (as in “recreate”) the snapshot (rather than: you can reproduce the error using the snapshot). My guess is, you were just saying the latter (in parentheses), as you otherwise probably would’ve already posted a similar list of reproduction steps as in your example of “issues with a "bad" nightly version causing unexpected errors”. Interestingly, now that you mention it, I remember seeing some `#[warn(unused_attributes)]` warnings, too; that was while I was building old rustc versions incrementally, recently. I should try reproducing those and see if they still apply to current compilers. |
|
@hudson-ayers you also ran into this right -- any chance your build is still around? |
|
I just saw it on Travis also, it didn't happen on my local machine |
Correct, I can reproduce the error using the snapshot, but I don't have the exact steps that led to it from the clean start. These steps were roughly (1) bump the nightly version in our Note: I don't know how related this is, but I also noticed that Cargo builds dependencies in an arbitrary order on each run, so even a step like
We observed it on Even though there is no clear reproduction steps, what is clear from these errors is the stack trace. Isn't it actionable? rust/src/librustc_middle/ty/query/on_disk_cache.rs Lines 456 to 458 in 8926bb4 The error message (
|
…70924, r=nikomatsakis run-make regression test for issue rust-lang#70924. Sometime after my PR rust-lang#72767 (to fix issue rust-lang#70924) landed, I realized that I *could* make a local regression test, thanks to `rustc --print sysroot`: I can make a fresh "copy" (really mostly symlinks) of the sysroot, and then modify it to recreate the terms of this bug.
…70924, r=nikomatsakis run-make regression test for issue rust-lang#70924. Sometime after my PR rust-lang#72767 (to fix issue rust-lang#70924) landed, I realized that I *could* make a local regression test, thanks to `rustc --print sysroot`: I can make a fresh "copy" (really mostly symlinks) of the sysroot, and then modify it to recreate the terms of this bug.
…70924, r=nikomatsakis run-make regression test for issue rust-lang#70924. Sometime after my PR rust-lang#72767 (to fix issue rust-lang#70924) landed, I realized that I *could* make a local regression test, thanks to `rustc --print sysroot`: I can make a fresh "copy" (really mostly symlinks) of the sysroot, and then modify it to recreate the terms of this bug.
…70924, r=nikomatsakis run-make regression test for issue rust-lang#70924. Sometime after my PR rust-lang#72767 (to fix issue rust-lang#70924) landed, I realized that I *could* make a local regression test, thanks to `rustc --print sysroot`: I can make a fresh "copy" (really mostly symlinks) of the sysroot, and then modify it to recreate the terms of this bug.
…70924, r=nikomatsakis run-make regression test for issue rust-lang#70924. Sometime after my PR rust-lang#72767 (to fix issue rust-lang#70924) landed, I realized that I *could* make a local regression test, thanks to `rustc --print sysroot`: I can make a fresh "copy" (really mostly symlinks) of the sysroot, and then modify it to recreate the terms of this bug.
…70924, r=nikomatsakis run-make regression test for issue rust-lang#70924. Sometime after my PR rust-lang#72767 (to fix issue rust-lang#70924) landed, I realized that I *could* make a local regression test, thanks to `rustc --print sysroot`: I can make a fresh "copy" (really mostly symlinks) of the sysroot, and then modify it to recreate the terms of this bug.
…70924, r=nikomatsakis run-make regression test for issue rust-lang#70924. Sometime after my PR rust-lang#72767 (to fix issue rust-lang#70924) landed, I realized that I *could* make a local regression test, thanks to `rustc --print sysroot`: I can make a fresh "copy" (really mostly symlinks) of the sysroot, and then modify it to recreate the terms of this bug.
…70924, r=nikomatsakis run-make regression test for issue rust-lang#70924. Sometime after my PR rust-lang#72767 (to fix issue rust-lang#70924) landed, I realized that I *could* make a local regression test, thanks to `rustc --print sysroot`: I can make a fresh "copy" (really mostly symlinks) of the sysroot, and then modify it to recreate the terms of this bug.
…70924, r=nikomatsakis run-make regression test for issue rust-lang#70924. Sometime after my PR rust-lang#72767 (to fix issue rust-lang#70924) landed, I realized that I *could* make a local regression test, thanks to `rustc --print sysroot`: I can make a fresh "copy" (really mostly symlinks) of the sysroot, and then modify it to recreate the terms of this bug.
…70924, r=nikomatsakis run-make regression test for issue rust-lang#70924. Sometime after my PR rust-lang#72767 (to fix issue rust-lang#70924) landed, I realized that I *could* make a local regression test, thanks to `rustc --print sysroot`: I can make a fresh "copy" (really mostly symlinks) of the sysroot, and then modify it to recreate the terms of this bug.
Rollup of 2 pull requests Successful merges: - rust-lang#72952 (run-make regression test for issue rust-lang#70924.) - rust-lang#72977 (Fix codegen tests for RISC-V) Failed merges: r? @ghost
Hi.
I did cargo build and suddenly this goes to my console:
I gave it another try and this is the backtrace:
https://pastebin.com/JLQy9Ear
I am using today nightly. It was compiling fine before... anyway as I believe that the problem is with panic - I am reporting this bug.
The text was updated successfully, but these errors were encountered: