-
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
Fix double-drop in Vec::from_iter(vec.into_iter())
specialization when items drop during panic
#83629
Conversation
r? @m-ou-se (rust-highfive has picked a reviewer for you, use r? to override) |
Yes. @bors r+ Thanks! |
📌 Commit 421f5d2 has been approved by |
…r=m-ou-se Fix double-drop in `Vec::from_iter(vec.into_iter())` specialization when items drop during panic This fixes the double-drop but it leaves a behavioral difference compared to the default implementation intact: In the default implementation the source and the destination vec are separate objects, so they get dropped separately. Here they share an allocation and the latter only exists as a pointer into the former. So if dropping the former panics then this fix will leak more items than the default implementation would. Is this acceptable or should the specialization also mimic the default implementation's drops-during-panic behavior? Fixes rust-lang#83618 `@rustbot` label T-libs-impl
Since the associated issue is labeled critical, should this go into beta too? |
…r=m-ou-se Fix double-drop in `Vec::from_iter(vec.into_iter())` specialization when items drop during panic This fixes the double-drop but it leaves a behavioral difference compared to the default implementation intact: In the default implementation the source and the destination vec are separate objects, so they get dropped separately. Here they share an allocation and the latter only exists as a pointer into the former. So if dropping the former panics then this fix will leak more items than the default implementation would. Is this acceptable or should the specialization also mimic the default implementation's drops-during-panic behavior? Fixes rust-lang#83618 `@rustbot` label T-libs-impl
let _ = v.into_iter().take(0).collect::<Vec<_>>(); | ||
})); | ||
|
||
assert_eq!(unsafe { DROP_COUNTER }, 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this test ensure to eventually actually free the memory that was "leaked" as part of the "panic during drop"?
If not, this would be a problem for running the test in Miri -- to ensure that the standard library is memory-leak-free, Miri errors. That's why other tests like this that already exist explicit free the "leaked" memory after the test is done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it doesn't free. Can you point to a test that does the explicit free so I can steal from that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think most tests just avoid having a Box
, so even if desturctors don't get called, there's no memory leak -- the DROP_COUNTER
is usually enough to check that everything is all right.
I thought there were also tests that used manual "late" deallocation of the Box
, but cannot find any... do you think checking DROP_COUNTER
is sufficient?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should be possible, yeah. I took the reproducer from #83629 which relied on a double-free to trigger malloc errors and converted it into a test-case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, that won't do since the vec's storage itself will also get leaked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, good point!
…r=m-ou-se Fix double-drop in `Vec::from_iter(vec.into_iter())` specialization when items drop during panic This fixes the double-drop but it leaves a behavioral difference compared to the default implementation intact: In the default implementation the source and the destination vec are separate objects, so they get dropped separately. Here they share an allocation and the latter only exists as a pointer into the former. So if dropping the former panics then this fix will leak more items than the default implementation would. Is this acceptable or should the specialization also mimic the default implementation's drops-during-panic behavior? Fixes rust-lang#83618 `@rustbot` label T-libs-impl
Rollup of 7 pull requests Successful merges: - rust-lang#83065 (Rework `std::sys::windows::alloc`) - rust-lang#83478 (rustdoc: Add unstable option to only emit shared/crate-specific files) - rust-lang#83629 (Fix double-drop in `Vec::from_iter(vec.into_iter())` specialization when items drop during panic) - rust-lang#83673 (give full path of constraint in suggest_constraining_type_param) - rust-lang#83755 (Simplify coverage tests) - rust-lang#83757 (2229: Support migration via rustfix) - rust-lang#83771 (Fix stack overflow detection on FreeBSD 11.1+) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This comment has been minimized.
This comment has been minimized.
72688e5
to
328a5e0
Compare
This needs another approval, I added one more commit to address the miri issue while the rollup was in flight. @rustbot label -S-waiting-on-bors +S-waiting-on-review |
I'm afraid changing a PR while a rollup is in flight will confuse things a bit.^^ Most of the commits of this one have landed as part of #83790, so I'll close this PR. It would be better to open a new PR, I think. |
FWIW, here is the anticipated leak -- looks like only one allocation actually leaked?
|
That should actually be correct. Without the fix the
Eh, git can deal with merging the same branch twice. But ok, I'll make a new PR. I can also add the box again. |
Thanks a lot! |
…r=RalfJung cleanup leak after test to make miri happy Contains changes that were requested in rust-lang#83629 but didn't make it into the rollup. r? `@RalfJung`
…r=RalfJung cleanup leak after test to make miri happy Contains changes that were requested in rust-lang#83629 but didn't make it into the rollup. r? ``@RalfJung``
…r=RalfJung cleanup leak after test to make miri happy Contains changes that were requested in rust-lang#83629 but didn't make it into the rollup. r? ```@RalfJung```
…r=RalfJung cleanup leak after test to make miri happy Contains changes that were requested in rust-lang#83629 but didn't make it into the rollup. r? ````@RalfJung````
…r=RalfJung cleanup leak after test to make miri happy Contains changes that were requested in rust-lang#83629 but didn't make it into the rollup. r? `````@RalfJung`````
This PR was cited as the fix for CVE-2021-31162, so I'm nominating it for beta. |
If miri tests are executed for beta builds you'll want #83827 too |
No, Miri is nightly-only. |
We discussed this in the compiler team triage meeting this morning and decided to approve for backport. |
[beta] backports This backports two beta-accepted PRs, fixing CVE-2020-36323 and CVE-2021-31162. - Fixes API soundness issue in `join()` rust-lang#81728 - Fix double-drop in `Vec::from_iter(vec.into_iter())` specialization when items drop during panic rust-lang#83629
This fixes the double-drop but it leaves a behavioral difference compared to the default implementation intact: In the default implementation the source and the destination vec are separate objects, so they get dropped separately. Here they share an allocation and the latter only exists as a pointer into the former. So if dropping the former panics then this fix will leak more items than the default implementation would. Is this acceptable or should the specialization also mimic the default implementation's drops-during-panic behavior?
Fixes #83618
@rustbot label T-libs-impl