Skip to content

v0.8: Prepare for the next release #1188

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

Merged
merged 2 commits into from
Apr 8, 2025
Merged

v0.8: Prepare for the next release #1188

merged 2 commits into from
Apr 8, 2025

Conversation

taiki-e
Copy link
Member

@taiki-e taiki-e commented Apr 8, 2025

Changes:

Also yanking crossbeam-channel 0.5.12, 0.5.13, 0.5.14.

petrosagg and others added 2 commits April 9, 2025 05:47
This PR is fixing a regression introduced by #1084 that can lead to a
double free when dropping the channel.

The method `Channel::discard_all_messages` has the property that if it
observes `head.block` pointing to a non-null pointer it will attempt to
free it.

The same property holds for the `Channel::drop` method and so it is
critical that whenever `head.block` is freed it must also be set to a
null pointer so that it is freed exactly once.

Before #1084 the behavior of `discard_all_messages` ensured `head.block`
was `null` after its execution due to the atomic store right before
exiting [1].

After #1084 `discard_all_messages` atomically swaps the current value of
`head.block` with a null pointer at the moment the value is read instead
of waiting for the end of the function.

The problem lies in the fact that `dicard_all_messages` contained two
paths that could lead to `head.block` being read but only one of them
would swap the value. This meant that `dicard_all_messages` could end up
observing a non-null block pointer (and therefore attempting to free it)
without setting `head.block` to null. This would then lead to
`Channel::drop` making a second attempt at dropping the same pointer.

The bug is similar to the one previously fixed by #972 and the double
free can be reproduced by reverting the reproduction commit from that PR
[2].

As with #972 it is quite difficult to trigger this bug without
introducing artificial sleeps in critical points so this PR does not
include a test.

[1] https://github.com/crossbeam-rs/crossbeam/blob/crossbeam-channel-0.5.11/crossbeam-channel/src/flavors/list.rs#L625
[2] 2d22628

Signed-off-by: Petros Angelatos <[email protected]>
- crossbeam-channel 0.5.14 -> 0.5.15

Also yanking crossbeam-channel 0.5.12, 0.5.13, 0.5.14.
@taiki-e taiki-e merged commit d35ffde into v0.8 Apr 8, 2025
22 checks passed
@taiki-e taiki-e deleted the v0.8-next branch April 8, 2025 21:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

2 participants