-
Notifications
You must be signed in to change notification settings - Fork 475
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 unsoundness issues (mem::zeroed / ManuallyDrop -> MaybeUninit) #458
Conversation
Thank you for the PR! Is it still in progress? Looks good to merge to me :) We also have some instances of uninitialized memory in bounded queues (files |
@stjepang Well, the issue is the MSRV bump to 1.36 (MaybeUninit), that's why I've opened this as a draft. So you are saying that we should go ahead with the MSRV bump?
Yes, I will update them shortly and mark this PR ready for review then :). |
@stjepang There is a failure in crossbeam's array flavoured channel: travis. ---- drops stdout ----
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `9336`,
right: `9338`', crossbeam-channel/tests/array.rs:533:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace. The MaybeUninit unsoundness fix should be right, unless I am missing something? EDIT: nvm I think I missed something, pushing the fix in a moment. |
@stjepang It's ready for review now. |
This PR is ready now. |
Friendly neighborhood ping. |
fyi: by using https://crates.io/crates/maybe-uninit crate, we can avoid the MSRV bump (like smallvec 0.6 did) |
@taiki-e that seems really appealing to me. |
I think we should just bump the minimum Rust version and consider publishing crossbeam 1.0 soon. A lot of unsafe code in crossbeam is really dealing with uninitialized memory so it's important we start using |
one final consideration, @stjepang mentioned to me yesterday that rayon lags by a year. bumping MSRV to 1.36 means they need to wait until July 4 2020 before they can reduce their reliance on the uninitialized usage here. By using the |
I would love to see this land so that miri will work on downstream crates like https://github.com/jonhoo/flurry too! |
@jeehoonkang @stjepang what are next steps for this PR? I think we need your decision for who to best move forward. It'd probably be good to land this PR in one form or another sooner rather than later. |
This removes the patch that incorporates crossbeam-rs/crossbeam#458, since that PR also bumps the version number, and 0.9 doesn't exist on crates.io. This in turn means that the miri test has to be disabled for this release in particular. I'll push a commit after release that restores it and the crossbeam patch. This commit also adds a changelog!
This removes the patch that incorporates crossbeam-rs/crossbeam#458, since that PR also bumps the version number, and 0.9 doesn't exist on crates.io. This in turn means that the miri test has to be disabled for this release in particular. I'll push a commit after release that restores it and the crossbeam patch. This commit also adds a changelog!
I prefer |
Thanks! @cynecx, do you have the time to update the PR to use |
@jonhoo Sure :) The changes should be up in an hour(-ish)! |
A question though, instead of adding |
I would keep it separate, since (I think) it's weird for |
If you reexport it, it becomes part of the public API, including the fact that it's identical to |
Whatever, seems like the review boxed are marked outdated anyway. |
3832f5a
to
a86b3b6
Compare
Thanks! bors r+ |
Build succeeded |
@jeehoonkang Nice, thanks! What's the plan for next release between this and #466 ? Would be good to land something soon to get those out. |
474: Patch release for all crossbeam crates. r=jeehoonkang a=jonhoo This bumps the patch version for all sub-crates and the top-level crate and updates the changelogs with references to PRs where applicable. As far as I can tell, there are no breaking changes. The top-level crate has not change at all, though I bumped `rand` to `0.7` in all the crates, which I guess technically requires a patch bump if we do another release. Fixes #473. Closes #472. Closes #468. Closes #409. Not sure if this also solves #347 by virtue of #458? Co-authored-by: Jon Gjengset <jon@thesquareplanet.com>
474: Patch release for all crossbeam crates. r=jeehoonkang a=jonhoo This bumps the patch version for all sub-crates and the top-level crate and updates the changelogs with references to PRs where applicable. As far as I can tell, there are no breaking changes. The top-level crate has not change at all, though I bumped `rand` to `0.7` in all the crates, which I guess technically requires a patch bump if we do another release. Fixes #473. Closes #472. Closes #468. Closes #409. Not sure if this also solves #347 by virtue of #458? Co-authored-by: Jon Gjengset <jon@thesquareplanet.com>
474: Patch release for all crossbeam crates. r=jeehoonkang a=jonhoo This bumps the patch version for all sub-crates and the top-level crate and updates the changelogs with references to PRs where applicable. As far as I can tell, there are no breaking changes. The top-level crate has not change at all, though I bumped `rand` to `0.7` in all the crates, which I guess technically requires a patch bump if we do another release. Fixes #473. Closes #472. Closes #468. Closes #409. Not sure if this also solves #347 by virtue of #458? Co-authored-by: Jon Gjengset <jon@thesquareplanet.com>
This adds one new dependency, maybe-uninit, which is brought in by crossbeam-channel[1]. This is to apparently fix some unsound code without bumping the MSRV. Since ripgrep uses the latest stable release of Rust, the maybe-uninit crate should compile down to nothing and just re-export std's `MaybeUninit` type. [1] - crossbeam-rs/crossbeam#458
774: Reduce unsafe code in array queue/bounded channel r=taiki-e a=taiki-e Before #458, since destructors could be called on elements, the correct way was to convert the Vec to a pointer, save it, and then [deallocate it as a Vec with zero length](https://github.com/crossbeam-rs/crossbeam/blob/28ad2b7e015832b47db7e389dd9ebce3e94b3adb/crossbeam-channel/src/flavors/array.rs#L549-L552). However, after #458, destructors of the elements wrapped by MaybeUninit are not called, so there is no need to save the Vec/boxed slice as a pointer. This removes the unsafe code that has caused several (potential) unsoundnesses in the past (#500, #533, #763). Co-authored-by: Taiki Endo <te316e89@gmail.com>
Several libs in crossbeam contain unsound code (eg.
Block::new
). This PR fixes them and requires a MSRV upgrade to 1.36.