Undetected use after move #18571
Comments
|
Nominating, seems like a soundness hole. |
|
This is an issue with zeroing dynamic drops (which are going to be removed: rust-lang/rfcs#320) – when A clearer example is: struct Test;
struct Test2 {
b: Option<Test>,
}
impl Drop for Test {
fn drop(&mut self) {
println!("Dropping");
}
}
#[cfg(leaks)]
impl Drop for Test2 {
fn drop(&mut self) {}
}
fn stuff() {
let mut t = Test2 { b: None };
let u = Test;
drop(t);
t.b = Some(u);
}
fn main() {
stuff();
} |
|
Structs that implement drop are not supposed to be in a partially initialized state. We already prevents moves out from individual fields, but we also need to prevent individual fields from being re-initialized. cc @zwarich since (iirc?) he was working on the patches that made us more accepting around re-initializing fields and so forth, and maybe this bug is of interest to him. |
|
So we are not supposed to allow structs that implement drop to be partially initialized. We already disallow going from fully-initialized to partially initialized. But it seems (from the first example) that we missed disallowing going from fully-uninitialized to partially initializd. That needs to be fixed. Assigning P-backcompat-lang, 1.0. |
enumerations that implement the `Drop` trait.
This breaks code like:
struct Struct {
f: String,
g: String,
}
impl Drop for Struct { ... }
fn main() {
let x = Struct { ... };
drop(x);
x.f = ...;
}
Change this code to not create partially-initialized structures. For
example:
struct Struct {
f: String,
g: String,
}
impl Drop for Struct { ... }
fn main() {
let x = Struct { ... };
drop(x);
x = Struct {
f: ...,
g: ...,
}
}
Closes rust-lang#18571.
[breaking-change]
|
While this will hopefully be fixed soon, as there is a PR up, it seems to have fallen through the cracks as a P-backcompat-lang issue that is only on the 1.0 milestone and not 1.0 beta. Nominating for 1.0 beta. (Also, I guess I will try to run through and find any other such overlooked issues.) |
enumerations that implement the `Drop` trait.
This breaks code like:
struct Struct {
f: String,
g: String,
}
impl Drop for Struct { ... }
fn main() {
let x = Struct { ... };
drop(x);
x.f = ...;
}
Change this code to not create partially-initialized structures. For
example:
struct Struct {
f: String,
g: String,
}
impl Drop for Struct { ... }
fn main() {
let x = Struct { ... };
drop(x);
x = Struct {
f: ...,
g: ...,
}
}
Closes rust-lang#18571.
[breaking-change]
----
(Joint authorship by pcwalton and Ryman; thanks all!)
enumerations that implement the `Drop` trait.
This breaks code like:
struct Struct {
f: String,
g: String,
}
impl Drop for Struct { ... }
fn main() {
let x = Struct { ... };
drop(x);
x.f = ...;
}
Change this code to not create partially-initialized structures. For
example:
struct Struct {
f: String,
g: String,
}
impl Drop for Struct { ... }
fn main() {
let x = Struct { ... };
drop(x);
x = Struct {
f: ...,
g: ...,
}
}
Closes rust-lang#18571.
[breaking-change]
|
Assigning 1.0 beta. |
So I was curious how Drop handles cycles, because this could lead to dangling pointers, which is why
__del__might not be called in Python. And indeed the below example does not call Drop.But
tis moved intou, so why does this compile at all?The text was updated successfully, but these errors were encountered: