bootstrap: Try to track down why initial_libdir sometimes fails
#129775
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Determining this path occasionally fails locally for unknown reasons, resulting in the build failing with an unhelpful `StripPrefixError(())` panic message. In order to track down why that's happening, include some relevant information in the panic message when that failure occurs.
|
rustbot has assigned @albertlarsan68. Use |
rustbot
added
S-waiting-on-review
|
LGTM |
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Sep 5, 2024
…arsan68 bootstrap: Try to track down why `initial_libdir` sometimes fails When I try to run `x` commands from the command-line, I occasionally see a mysterious failure that looks something like this: ```text thread 'main' panicked at src/lib.rs:341:14: called `Result::unwrap()` on an `Err` value: StripPrefixError(()) ``` It happens often enough to be annoying, but rarely enough that I can't reproduce it at will. The error message points to a particular `unwrap` call, but doesn't include enough context to determine *why* the failure occurs. Re-running the command almost always works, so I suspect some kind of filesystem race condition (possibly involving VSCode invoking bootstrap at the same time), but there's not much I can do with the information I currently have. So this PR includes some relevant information in the panic message when the failure occurs, in the hope that doing so will make the cause easier to track down when the failure occurs again.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Sep 5, 2024
…arsan68 bootstrap: Try to track down why `initial_libdir` sometimes fails When I try to run `x` commands from the command-line, I occasionally see a mysterious failure that looks something like this: ```text thread 'main' panicked at src/lib.rs:341:14: called `Result::unwrap()` on an `Err` value: StripPrefixError(()) ``` It happens often enough to be annoying, but rarely enough that I can't reproduce it at will. The error message points to a particular `unwrap` call, but doesn't include enough context to determine *why* the failure occurs. Re-running the command almost always works, so I suspect some kind of filesystem race condition (possibly involving VSCode invoking bootstrap at the same time), but there's not much I can do with the information I currently have. So this PR includes some relevant information in the panic message when the failure occurs, in the hope that doing so will make the cause easier to track down when the failure occurs again.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 5, 2024
…iaskrgr Rollup of 12 pull requests Successful merges: - rust-lang#128919 (Add an internal lint that warns when accessing untracked data) - rust-lang#129471 ([rustdoc] Sort impl associated items by kinds and then by appearance) - rust-lang#129653 (clarify that addr_of creates read-only pointers) - rust-lang#129775 (bootstrap: Try to track down why `initial_libdir` sometimes fails) - rust-lang#129939 (explain why Rvalue::Len still exists) - rust-lang#129940 (s390x: Fix a regression related to backchain feature) - rust-lang#129942 (copy rustc rustlib artifacts from ci-rustc) - rust-lang#129943 (use the bootstrapped compiler for `test-float-parse` test) - rust-lang#129944 (Add compat note for trait solver change) - rust-lang#129947 (Add digit separators in `Duration` examples) - rust-lang#129955 (Temporarily remove fmease from the review rotation) - rust-lang#129957 (forward linker option to lint-docs) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 5, 2024
…iaskrgr Rollup of 12 pull requests Successful merges: - rust-lang#128919 (Add an internal lint that warns when accessing untracked data) - rust-lang#129471 ([rustdoc] Sort impl associated items by kinds and then by appearance) - rust-lang#129653 (clarify that addr_of creates read-only pointers) - rust-lang#129775 (bootstrap: Try to track down why `initial_libdir` sometimes fails) - rust-lang#129939 (explain why Rvalue::Len still exists) - rust-lang#129940 (s390x: Fix a regression related to backchain feature) - rust-lang#129942 (copy rustc rustlib artifacts from ci-rustc) - rust-lang#129943 (use the bootstrapped compiler for `test-float-parse` test) - rust-lang#129944 (Add compat note for trait solver change) - rust-lang#129947 (Add digit separators in `Duration` examples) - rust-lang#129955 (Temporarily remove fmease from the review rotation) - rust-lang#129957 (forward linker option to lint-docs) r? `@ghost` `@rustbot` modify labels: rollup
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Sep 5, 2024
…arsan68 bootstrap: Try to track down why `initial_libdir` sometimes fails When I try to run `x` commands from the command-line, I occasionally see a mysterious failure that looks something like this: ```text thread 'main' panicked at src/lib.rs:341:14: called `Result::unwrap()` on an `Err` value: StripPrefixError(()) ``` It happens often enough to be annoying, but rarely enough that I can't reproduce it at will. The error message points to a particular `unwrap` call, but doesn't include enough context to determine *why* the failure occurs. Re-running the command almost always works, so I suspect some kind of filesystem race condition (possibly involving VSCode invoking bootstrap at the same time), but there's not much I can do with the information I currently have. So this PR includes some relevant information in the panic message when the failure occurs, in the hope that doing so will make the cause easier to track down when the failure occurs again.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 5, 2024
…iaskrgr Rollup of 12 pull requests Successful merges: - rust-lang#128919 (Add an internal lint that warns when accessing untracked data) - rust-lang#129472 (fix ICE when `asm_const` and `const_refs_to_static` are combined) - rust-lang#129653 (clarify that addr_of creates read-only pointers) - rust-lang#129775 (bootstrap: Try to track down why `initial_libdir` sometimes fails) - rust-lang#129939 (explain why Rvalue::Len still exists) - rust-lang#129940 (s390x: Fix a regression related to backchain feature) - rust-lang#129942 (copy rustc rustlib artifacts from ci-rustc) - rust-lang#129943 (use the bootstrapped compiler for `test-float-parse` test) - rust-lang#129944 (Add compat note for trait solver change) - rust-lang#129947 (Add digit separators in `Duration` examples) - rust-lang#129955 (Temporarily remove fmease from the review rotation) - rust-lang#129957 (forward linker option to lint-docs) Failed merges: - rust-lang#129471 ([rustdoc] Sort impl associated items by kinds and then by appearance) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 5, 2024
…iaskrgr Rollup of 12 pull requests Successful merges: - rust-lang#128919 (Add an internal lint that warns when accessing untracked data) - rust-lang#129472 (fix ICE when `asm_const` and `const_refs_to_static` are combined) - rust-lang#129653 (clarify that addr_of creates read-only pointers) - rust-lang#129775 (bootstrap: Try to track down why `initial_libdir` sometimes fails) - rust-lang#129939 (explain why Rvalue::Len still exists) - rust-lang#129940 (s390x: Fix a regression related to backchain feature) - rust-lang#129942 (copy rustc rustlib artifacts from ci-rustc) - rust-lang#129943 (use the bootstrapped compiler for `test-float-parse` test) - rust-lang#129944 (Add compat note for trait solver change) - rust-lang#129947 (Add digit separators in `Duration` examples) - rust-lang#129955 (Temporarily remove fmease from the review rotation) - rust-lang#129957 (forward linker option to lint-docs) Failed merges: - rust-lang#129471 ([rustdoc] Sort impl associated items by kinds and then by appearance) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 5, 2024
…iaskrgr Rollup of 12 pull requests Successful merges: - rust-lang#128919 (Add an internal lint that warns when accessing untracked data) - rust-lang#129472 (fix ICE when `asm_const` and `const_refs_to_static` are combined) - rust-lang#129653 (clarify that addr_of creates read-only pointers) - rust-lang#129775 (bootstrap: Try to track down why `initial_libdir` sometimes fails) - rust-lang#129939 (explain why Rvalue::Len still exists) - rust-lang#129940 (s390x: Fix a regression related to backchain feature) - rust-lang#129942 (copy rustc rustlib artifacts from ci-rustc) - rust-lang#129943 (use the bootstrapped compiler for `test-float-parse` test) - rust-lang#129944 (Add compat note for trait solver change) - rust-lang#129947 (Add digit separators in `Duration` examples) - rust-lang#129955 (Temporarily remove fmease from the review rotation) - rust-lang#129957 (forward linker option to lint-docs) Failed merges: - rust-lang#129471 ([rustdoc] Sort impl associated items by kinds and then by appearance) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 5, 2024
…iaskrgr Rollup of 11 pull requests Successful merges: - rust-lang#128919 (Add an internal lint that warns when accessing untracked data) - rust-lang#129472 (fix ICE when `asm_const` and `const_refs_to_static` are combined) - rust-lang#129653 (clarify that addr_of creates read-only pointers) - rust-lang#129775 (bootstrap: Try to track down why `initial_libdir` sometimes fails) - rust-lang#129939 (explain why Rvalue::Len still exists) - rust-lang#129942 (copy rustc rustlib artifacts from ci-rustc) - rust-lang#129943 (use the bootstrapped compiler for `test-float-parse` test) - rust-lang#129944 (Add compat note for trait solver change) - rust-lang#129947 (Add digit separators in `Duration` examples) - rust-lang#129955 (Temporarily remove fmease from the review rotation) - rust-lang#129957 (forward linker option to lint-docs) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 5, 2024
…iaskrgr Rollup of 11 pull requests Successful merges: - rust-lang#128919 (Add an internal lint that warns when accessing untracked data) - rust-lang#129472 (fix ICE when `asm_const` and `const_refs_to_static` are combined) - rust-lang#129653 (clarify that addr_of creates read-only pointers) - rust-lang#129775 (bootstrap: Try to track down why `initial_libdir` sometimes fails) - rust-lang#129939 (explain why Rvalue::Len still exists) - rust-lang#129942 (copy rustc rustlib artifacts from ci-rustc) - rust-lang#129943 (use the bootstrapped compiler for `test-float-parse` test) - rust-lang#129944 (Add compat note for trait solver change) - rust-lang#129947 (Add digit separators in `Duration` examples) - rust-lang#129955 (Temporarily remove fmease from the review rotation) - rust-lang#129957 (forward linker option to lint-docs) r? `@ghost` `@rustbot` modify labels: rollup
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Sep 6, 2024
…arsan68 bootstrap: Try to track down why `initial_libdir` sometimes fails When I try to run `x` commands from the command-line, I occasionally see a mysterious failure that looks something like this: ```text thread 'main' panicked at src/lib.rs:341:14: called `Result::unwrap()` on an `Err` value: StripPrefixError(()) ``` It happens often enough to be annoying, but rarely enough that I can't reproduce it at will. The error message points to a particular `unwrap` call, but doesn't include enough context to determine *why* the failure occurs. Re-running the command almost always works, so I suspect some kind of filesystem race condition (possibly involving VSCode invoking bootstrap at the same time), but there's not much I can do with the information I currently have. So this PR includes some relevant information in the panic message when the failure occurs, in the hope that doing so will make the cause easier to track down when the failure occurs again.
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Sep 6, 2024
…arsan68 bootstrap: Try to track down why `initial_libdir` sometimes fails When I try to run `x` commands from the command-line, I occasionally see a mysterious failure that looks something like this: ```text thread 'main' panicked at src/lib.rs:341:14: called `Result::unwrap()` on an `Err` value: StripPrefixError(()) ``` It happens often enough to be annoying, but rarely enough that I can't reproduce it at will. The error message points to a particular `unwrap` call, but doesn't include enough context to determine *why* the failure occurs. Re-running the command almost always works, so I suspect some kind of filesystem race condition (possibly involving VSCode invoking bootstrap at the same time), but there's not much I can do with the information I currently have. So this PR includes some relevant information in the panic message when the failure occurs, in the hope that doing so will make the cause easier to track down when the failure occurs again.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 6, 2024
…iaskrgr Rollup of 11 pull requests Successful merges: - rust-lang#128919 (Add an internal lint that warns when accessing untracked data) - rust-lang#129472 (fix ICE when `asm_const` and `const_refs_to_static` are combined) - rust-lang#129653 (clarify that addr_of creates read-only pointers) - rust-lang#129775 (bootstrap: Try to track down why `initial_libdir` sometimes fails) - rust-lang#129939 (explain why Rvalue::Len still exists) - rust-lang#129942 (copy rustc rustlib artifacts from ci-rustc) - rust-lang#129943 (use the bootstrapped compiler for `test-float-parse` test) - rust-lang#129944 (Add compat note for trait solver change) - rust-lang#129947 (Add digit separators in `Duration` examples) - rust-lang#129955 (Temporarily remove fmease from the review rotation) - rust-lang#129957 (forward linker option to lint-docs) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 6, 2024
…kingjubilee Rollup of 14 pull requests Successful merges: - rust-lang#128919 (Add an internal lint that warns when accessing untracked data) - rust-lang#129021 (Check WF of source type's signature on fn pointer cast) - rust-lang#129472 (fix ICE when `asm_const` and `const_refs_to_static` are combined) - rust-lang#129653 (clarify that addr_of creates read-only pointers) - rust-lang#129775 (bootstrap: Try to track down why `initial_libdir` sometimes fails) - rust-lang#129781 (Make `./x.py <cmd> compiler/<crate>` aware of the crate's features) - rust-lang#129939 (explain why Rvalue::Len still exists) - rust-lang#129942 (copy rustc rustlib artifacts from ci-rustc) - rust-lang#129944 (Add compat note for trait solver change) - rust-lang#129947 (Add digit separators in `Duration` examples) - rust-lang#129955 (Temporarily remove fmease from the review rotation) - rust-lang#129957 (forward linker option to lint-docs) - rust-lang#129969 (Make `Ty::boxed_ty` return an `Option`) - rust-lang#129995 (Remove wasm32-wasip2's tier 2 status from release notes) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 6, 2024
Rollup merge of rust-lang#129775 - Zalathar:initial-libdir, r=albertlarsan68 bootstrap: Try to track down why `initial_libdir` sometimes fails When I try to run `x` commands from the command-line, I occasionally see a mysterious failure that looks something like this: ```text thread 'main' panicked at src/lib.rs:341:14: called `Result::unwrap()` on an `Err` value: StripPrefixError(()) ``` It happens often enough to be annoying, but rarely enough that I can't reproduce it at will. The error message points to a particular `unwrap` call, but doesn't include enough context to determine *why* the failure occurs. Re-running the command almost always works, so I suspect some kind of filesystem race condition (possibly involving VSCode invoking bootstrap at the same time), but there's not much I can do with the information I currently have. So this PR includes some relevant information in the panic message when the failure occurs, in the hope that doing so will make the cause easier to track down when the failure occurs again.
|
Here's the first failure I observed since this landed: Examining the paths side-by-side: During normal (successful) runs, the sysroot path is |
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Sep 14, 2024
…arsan68 bootstrap: Print more debug info when `find_initial_libdir` fails From looking at the failure messages printed by rust-lang#129775, my hypothesis is that `rustc --print=sysroot` sometimes prints the wrong path when the rustc executable is hardlinked in multiple places, at least on my macOS system. However, currently I don't have any concrete evidence of this actually happening. This PR therefore expands on rust-lang#129775 by printing even more information on failure (including the actual rustc path), in the hope that when the failure next occurs we can confirm or reject the hypothesis that `rustc --print=sysroot` is printing the wrong path.
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 14, 2024
Rollup merge of rust-lang#130138 - Zalathar:initial-libdir, r=albertlarsan68 bootstrap: Print more debug info when `find_initial_libdir` fails From looking at the failure messages printed by rust-lang#129775, my hypothesis is that `rustc --print=sysroot` sometimes prints the wrong path when the rustc executable is hardlinked in multiple places, at least on my macOS system. However, currently I don't have any concrete evidence of this actually happening. This PR therefore expands on rust-lang#129775 by printing even more information on failure (including the actual rustc path), in the hope that when the failure next occurs we can confirm or reject the hypothesis that `rustc --print=sysroot` is printing the wrong path.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When I try to run
xcommands from the command-line, I occasionally see a mysterious failure that looks something like this:It happens often enough to be annoying, but rarely enough that I can't reproduce it at will. The error message points to a particular
unwrapcall, but doesn't include enough context to determine why the failure occurs.Re-running the command almost always works, so I suspect some kind of filesystem race condition (possibly involving VSCode invoking bootstrap at the same time), but there's not much I can do with the information I currently have.
So this PR includes some relevant information in the panic message when the failure occurs, in the hope that doing so will make the cause easier to track down when the failure occurs again.