-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Objects can be dropped an arbitrary number of times in safe code #25549
Comments
Nominating for P-high |
cc @pnkfelix |
Too bad this doesn't just cancel out the Leakocalypse 😛 |
(well, any object that implements |
@pnkfelix look, no fn drop_n_times<T>(val: T, times: u32) {
struct Holder<T: ?Sized>(T);
let container = Holder([val]);
for _ in 0..times {
&(*(&container as &Holder<[T]>)).0;
}
} |
to be clear, I am looking at this now as well. :) |
I guess #22815 is related. |
@pnkfelix Yeah, it's unrelated. The |
When taking the address of an unsized field we generate a rvalue datum for the field and then convert it to an lvalue datum. At that point, cleanup is scheduled for the field, leading to multiple drop calls. The problem is that we generate an rvalue datum for the field, since the pointer does not own the data and there's already cleanup scheduled elsewhere by the true owner. Instead, an lvalue datum must be created. Thanks to @eddyb for identifying the underlying cause and suggesting the correct fix. Fixes rust-lang#25549.
When taking the address of an unsized field we generate a rvalue datum for the field and then convert it to an lvalue datum. At that point, cleanup is scheduled for the field, leading to multiple drop calls. The problem is that we generate an rvalue datum for the field, since the pointer does not own the data and there's already cleanup scheduled elsewhere by the true owner. Instead, an lvalue datum must be created. Thanks to @eddyb for identifying the underlying cause and suggesting the correct fix. Fixes rust-lang#25549 Fixes rust-lang#25515
When taking the address of an unsized field we generate a rvalue datum for the field and then convert it to an lvalue datum. At that point, cleanup is scheduled for the field, leading to multiple drop calls. The problem is that we generate an rvalue datum for the field, since the pointer does not own the data and there's already cleanup scheduled elsewhere by the true owner. Instead, an lvalue datum must be created. Thanks to @eddyb for identifying the underlying cause and suggesting the correct fix. Fixes #25549.
The following function can drop any object arbitrary number of times, using only safe code:
Probably bad :)
Found while researching #25515
The text was updated successfully, but these errors were encountered: