-
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
Segfault in a compiler-generated Drop impl #29092
Comments
Doing |
Reproduces for me only without any debuginfo. Both level 1 and 2 make the problem disappear, as do optimizations. |
use self::Term::*;
#[derive(Clone)]
pub enum Term {
True,
False,
If(Box<Term>),
}
// a small-step evaluator
pub fn small_eval(v: Term) -> Term {
match v {
If(ref con) => match **con {
True => True,
False => *con.clone(),
_ => True,
},
_ => True,
}
}
fn main() {
small_eval(If(Box::new(True)));
} still segfaults for me. |
Minimized even further: use self::Term::*;
#[derive(Clone)]
pub enum Term {
True,
False,
If(Box<Term>),
}
// a small-step evaluator
pub fn small_eval(v: Term) -> Term {
match v {
If(ref con) => match **con {
True => True,
_ => *con.clone(),
},
_ => True,
}
}
fn main() {
small_eval(If(Box::new(True)));
} The crash happens because the drop for the |
Adding braces around |
@dotdash The smallest example you posted repros in the same manner (that is, only no-op without debuginfo). |
Eliminated the need for the nested match. use self::Term::*;
#[derive(Clone)]
pub enum Term {
Dummy,
A(Box<Term>),
B(Box<Term>),
}
// a small-step evaluator
pub fn small_eval(v: Term) -> Term {
match v {
A(t) => *t.clone(),
B(t) => *t.clone(),
_ => Dummy,
}
}
fn main() {
small_eval(Dummy);
} @nikomatsakis You said that you think that we might be missing a drop initializer, but I don't think that's the case. It's not the match binding that's being dropped, but the expression in the match arm. Initializing that to a dropped value wouldn't do anything because the initialization would also happen in the match arm, which is never executed. |
(revised title based on @dotdash observations) |
I cannot reproduce this anymore, and in any case, I suspect it would be fixed by #30823 |
(The given test still readily reproduces the bug on the playpen, so I'll throw a regression test for this into the mix for #30823.) |
…st-lang#30530, rust-lang#30822. Note that the test for rust-lang#30822 is folded into the test for rust-lang#30530 (but the file name mentions only 30530).
…r-issue-30530, r=dotdash Put back alloca zeroing for issues rust-lang#29092, rust-lang#30018, rust-lang#30530; inject zeroing for rust-lang#30822. ---- Background context: `fn alloca_zeroed` was removed in PR rust-lang#22969, so we haven't been "zero'ing" (\*) the alloca's since at least that point, but the logic behind that PR seems sound, so its not entirely obvious how *long* the underlying bug has actually been present. In other words, I have not yet done a survey to see when the new `alloc_ty` and `lvalue_scratch_datum` calls were introduced that should have had "zero'ing" the alloca's. ---- I first fixed rust-lang#30018, then decided to do a survey of `alloc_ty` calls to see if they needed similar treatment, which quickly led to a rediscovery of rust-lang#30530. While making the regression test for the latter, I discovered rust-lang#30822, which is a slightly different bug (in terms of where the "zero'ing" needs to go), but still relevant. I haven't finished the aforementioned survey of `fn alloc_ty` calls, but I decided I wanted to get this up for review in its current state (namely to see if my attempt to force developers to include a justification for passing `Uninit` can possibly fly, or if I should abandon that path of action). ---- (*): I am putting quotation marks around "zero'ing" because we no longer use zero as our "dropped" marker value. Fix rust-lang#29092 Fix rust-lang#30018 Fix rust-lang#30530 Fix rust-lang#30822
I've tried reducing this code in various ways, and unfortunately the original seems to already be the smallest that fails! Removing variants from
Term
causes it to not exhibit itself, as does removing cases from the outermatch
insmall_eval
. It reproduces on latest nightly only if debuginfo=2, but on older nightlies (@Aatch reports a repro on 2015-09-22) or 1.3.0 it repros for debuginfo=1. On all versions, doing optimizations causes the issue to disappear.I suspect that an alloca (forced by debuginfo) is getting trampled somewhere.
GDB backtrace (from rustc 1.5.0-nightly (eafe106 2015-10-15)):
The text was updated successfully, but these errors were encountered: