-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Memory corruption (?) from tower-grpc-build on nightly #47175
Comments
cc @rust-lang/infra -- any chance somebody can bisect this a bit to see where the problem started? |
triage: P-high |
If it helps, this one goes through (
And this one fails (
Anything more exact would need setting up of some non-trivial infrastructure on my own computer. |
Given the range 9389e23...b65f0be I'm pretty sure it is #46735, but let me bisect anyway... Edit: |
cc @Manishearth |
Reductions:
|
Bisecting in the range 9389e23...8e7a609 Test script: #!/bin/sh
set -eu
$RUSTC_RELATIVE 1.rs
! ./1 ( Bisect result:
So yeah the cause is definitely #46735, and since it slips into beta it affects 1.24 beta as well. |
Huh. Wat. I'll fix this tomorrow. |
Okay, so the bug seems to be a discrepancy in how I thought the searcher API is supposed to work. let pb_ident = "p.q";
let mut searcher = '.'.into_searcher(pb_ident);
println!("{:?} {:?}", searcher.next_match_back(), searcher.next_match()); in old Rust this returns Some(1,2) and None, in new Rust it returns the same thing twice. I was under the impression that double ended searchers had independent fingers, but this seems to be wrong. We really need to overhaul this API so that it actually makes sense. |
Fixed in #47208 r? |
Make double ended searchers use dependent fingers (fixes #47175) r? @BurntSushi @alexcrichton needs uplift to beta
@Manishearth Our build is crashing through this bug. Nightly is green again after this PR was merged, however beta is still red. Will beta still be rolled out to stable and break our build in a few weeks? Or will there be a beta hotfix with this PR included? |
It's been marked beta-nominated, so it will be included before we make a stable release. I don't know if it will be included in a new beta before that. Either way, I'm the wrong person to ask, @alexcrichton would know |
Yes, we will (likely) publish a new beta with this backport. There's 5(?) weeks before the next release, so we'll need at least 2-3 more betas probably |
Awesome! Thanks for clarifying. |
@SirVer I believe the latest beta should have the fix (.2). |
Upstream bug rust-lang/rust#47175 is fixed, so we enable beta again as required for passing.
Upstream bug rust-lang/rust#47175 is fixed, so we enable beta again as required for passing.
Hello
When playing with some development versions of tower-grpc-build (https://github.com/tower-rs/tower/grpc), I discovered a strange crash of the build script. I managed to shring it a bit, but I don't think this is minimal case (I just don't know how to continue pinning it down further).
Few observations:
As I needed to pin exact commits in
Cargo.lock
to make the branches and crates from git to compile together, I have the example as a whole repository: https://github.com/vorner/p-crash.Steps to reproduce (I moved the failing code from build script to ordinary
main.rs
, therefore theOUT_DIR
):The backtrace:
It is likely something fishy is happening in some of the development branches, but I still suspect something strange happening in the compiler, both because of the uninitialized memory (or, memory looking uninitialized) and because it passes on stable, but not nightly.
The text was updated successfully, but these errors were encountered: