-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
btree: don't leak value if destructor of key panics #132597
Conversation
@bors r+ |
btree: don't leak value if destructor of key panics This PR fixes a regression from rust-lang#84904. The `BTreeMap` already attempts to handle panicking destructors of the key-value pairs by continuing to execute the remaining destructors after one destructor panicked. However, after rust-lang#84904 the destructor of a value in a key-value pair gets skipped if the destructor of the key panics, only continuing with the next key-value pair. This PR reverts to the behavior before rust-lang#84904 to also drop the corresponding value if the destructor of a key panics. This avoids potential memory leaks and can fix the soundness of programs that rely on the destructors being executed (even though this should not be relied upon, because the std collections currently do not guarantee that the remaining elements are dropped after a panic in a destructor). cc `@Amanieu` because you had opinions on panicking destructors
…mpiler-errors Rollup of 8 pull requests Successful merges: - rust-lang#131505 (use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` as a `TMPDIR` fallback on Darwin) - rust-lang#131859 (Update TRPL to add new Chapter 17: Async and Await) - rust-lang#132090 (Stop being so bail-y in candidate assembly) - rust-lang#132597 (btree: don't leak value if destructor of key panics) - rust-lang#132911 (Pretty print async fn sugar in opaques and trait bounds) - rust-lang#133159 (Don't allow `-Zunstable-options` to take a value ) - rust-lang#133247 (Reduce integer `Display` implementation size) - rust-lang#133286 (Re-delay a resolve `bug` related to `Self`-ctor in patterns) Failed merges: - rust-lang#133215 (Fix missing submodule in `./x vendor`) r? `@ghost` `@rustbot` modify labels: rollup
Failed in a rollup: #133350 (comment) @bors r- |
☀️ Test successful - checks-actions |
Finished benchmarking commit (124eb96): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -2.8%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -3.3%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResults (primary 0.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 797.356s -> 796.612s (-0.09%) |
This PR fixes a regression from #84904.
The
BTreeMap
already attempts to handle panicking destructors of the key-value pairs by continuing to execute the remaining destructors after one destructor panicked. However, after #84904 the destructor of a value in a key-value pair gets skipped if the destructor of the key panics, only continuing with the next key-value pair. This PR reverts to the behavior before #84904 to also drop the corresponding value if the destructor of a key panics.This avoids potential memory leaks and can fix the soundness of programs that rely on the destructors being executed (even though this should not be relied upon, because the std collections currently do not guarantee that the remaining elements are dropped after a panic in a destructor).
cc @Amanieu because you had opinions on panicking destructors