-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Print a backtrace when query forcing fails. #91742
Conversation
r? @estebank (rust-highfive has picked a reviewer for you, use r? to override) |
958e8af
to
72e15e4
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 72e15e4c1be2deb6b0f992c3d456845c65d2e268 with merge 2983d878369251d21927e651000a8ff8ec49de90... |
☀️ Try build successful - checks-actions |
Queued 2983d878369251d21927e651000a8ff8ec49de90 with parent 0b42dea, future comparison URL. |
Finished benchmarking commit (2983d878369251d21927e651000a8ff8ec49de90): comparison url. Summary: This change led to very large relevant regressions 😿 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 65c3ca2e6b1bea9e1b648aebf878cf012efe5000 with merge 8bb5f28b3708053643baaeb7e07417b143f54496... |
☀️ Try build successful - checks-actions |
Queued 8bb5f28b3708053643baaeb7e07417b143f54496 with parent 4a66a70, future comparison URL. |
Finished benchmarking commit (8bb5f28b3708053643baaeb7e07417b143f54496): comparison url. Summary: This change led to large relevant regressions 😿 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never |
.map(|dep_node_index| (prev_index, dep_node_index)); | ||
|
||
// We succeeded, forego printing a backtrace. | ||
std::mem::forget(_backtrace_print); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this a memory leak?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MarkingStack
only contains three references, so forgetting it cannot create a memory leak. The backing memory of the SmallVec
is correctly dropped since it's in a separate local. I'll add a comment.
r? rust-lang/compiler Punting this on the team because I'm not as familiar with the intricacies of the query system and I'm not sure how far the implications of this change can be ^_^' Given the perf impact it might make sense to put it behind an opt-in flag (maybe insta-stable so that we can mention it in the panic so that people can rerun and send us a report with the info? Ideally this would be always on if we can make the perf hit negligent.) |
.map(|dep_node_index| (prev_index, dep_node_index)); | ||
|
||
// We succeeded, forego printing a backtrace. | ||
std::mem::forget(_backtrace_print); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A rough look at perf statistics suggests that the main cost is in allocations -- it might make sense to try replacing smallvec with just storing the top 8 or 16 or whatever indices, and stopping there? It's not storing the full stack, but not sure that's actually necessary either?
⌛ Testing commit 870dd16 with merge 5a11a18d967fd55a839556407df0851878dca425... |
💥 Test timed out |
@bors r=estebank |
💡 This pull request was already approved, no need to approve it again.
|
🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened. |
☀️ Test successful - checks-actions |
Finished benchmarking commit (f0bc76a): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
The compiler team anticipated fallout here, and the actual fallout seems to roughly match. marking as triaged. @rustbot label: +perf-regression-triaged |
Optimize dep node backtrace and ignore fatal errors This attempts to optimize rust-lang#91742 while also passing through fatal errors. r? `@cjgillot`
Optimize dep node backtrace and ignore fatal errors This attempts to optimize rust-lang/rust#91742 while also passing through fatal errors. r? `@cjgillot`
Optimize dep node backtrace and ignore fatal errors This attempts to optimize rust-lang/rust#91742 while also passing through fatal errors. r? `@cjgillot`
Optimize dep node backtrace and ignore fatal errors This attempts to optimize rust-lang/rust#91742 while also passing through fatal errors. r? `@cjgillot`
The aim of this PR is to help debugging incremental compilation bugs where query forcing panics.
For instance: #90682 #90697 #90715 #90739 #91401
These bugs happen when the dep-graph attempts to force a dep-node whose fingerprint does not correspond to an actual DefPathHash. PR #91741 attempts to hide this bug.
I still don't know how to reproduce these bugs, so I sadly could not test this debugging device.