-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-destructorsArea: Destructors (`Drop`, …)Area: Destructors (`Drop`, …)A-lifetimesArea: Lifetimes / regionsArea: Lifetimes / regionsI-crashIssue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
Description
This struct has a borrowed pointer to another one of itself. By making it mutable, I can build a cycle, and then no matter the order that the destructors run, the second one will segfault because the first one's id will have been freed.
This is sort of related to #3164, and more closely related to #3039.
Probably accessing mutable &-pointers in destructors should be unsafe. If they are immutable, it should be impossible to build a cycle.
struct oops {
mut a: option<&oops>;
id: ~~str;
new(+a: option<&oops>, +id: ~~str) {
self.a = a; self.id = id;
}
drop {
do self.a.iter |nbr| {
#error["Me: %?; Neighbour: %?", self.id, nbr.id];
}
}
}
fn main() {
let x = oops(none, ~~"x");
let y = oops(some(&x), ~~"y");
x.a = some(&y);
}
Metadata
Metadata
Assignees
Labels
A-destructorsArea: Destructors (`Drop`, …)Area: Destructors (`Drop`, …)A-lifetimesArea: Lifetimes / regionsArea: Lifetimes / regionsI-crashIssue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.