Repository navigation
std::thread::JoinGuard (and scoped) are unsound because of reference cycles #24292
Description
You can use a reference cycle to leak a JoinGuard and then the scoped thread can access freed memory:
use std::thread;
use std::sync::atomic::AtomicBool;
use std::sync::atomic::Ordering::SeqCst;
use std::rc::Rc;
use std::cell::RefCell;
struct Evil<'a> {
link: RefCell<Option<Rc<Rc<Evil<'a>>>>>,
arm: thread::JoinGuard<'a, ()>
}
// This reliably observes an immutable reference mutating.
fn bad(g: &AtomicBool, v: &u64) {
let jg = thread::scoped(move || {
while !g.load(SeqCst) { }; // Wait for the reference to change
println!("{}", *v); // Observe it
g.store(false, SeqCst); // Safely exit without crashing
});
let e = Rc::new(Evil {
link: RefCell::new(None),
arm: jg
});
*e.link.borrow_mut() = Some(Rc::new(e.clone())); // Create a cycle
}
#[inline(never)] // Prevent DSE
fn helper(v: &mut Result<u64, &'static str>) {
let g = AtomicBool::new(false); // Used as a barrier to ensure reliable execution
if let &mut Ok(ref v) = v { bad(&g, &v) };
*v = Err("foo");
g.store(true, SeqCst);
while g.load(SeqCst) {};
}
fn main() {
helper(&mut Ok(4));
}
Activity
[-]std::thread::JoinGuard is unsound because of reference cycles[/-][+]std::thread::JoinGuard (and scoped) are unsound because of reference cycles[/+]sfackler commentedon Apr 10, 2015
Seems pretty bad, nominating.
nikomatsakis commentedon Apr 10, 2015
Sigh. Good point! This seems very similar to the dropck rules, I suspect we can address it in a similar fashion to how we addressed
Arena. But I have to have a bit more caffeine and try to work it through to make sure I'm correct. :)cc @pnkfelix
UPDATE: Spelled out what I meant a bit more.
arielb1 commentedon Apr 10, 2015
@sfackler
I don't think this is so bad, because I can't really think of this happening accidentally. I think the best way to fix this would be to add a
LeakOIBIT and makeRc/Arcrequire it. We may want to make it a by-default bound (likeSized), through, to prevent massive annotation burden.nikomatsakis commentedon Apr 10, 2015
triage: P-backcompat-libs (1.0)
I definitely think we need to address this for 1.0. I'm still not sure the best way to do it.
De-stabilize `thread::scoped` and friends
De-stabilize `thread::scoped` and friends
47 remaining items
nicola-gigante commentedon Sep 5, 2015
Interesting! Can you point me to the place (if any) where people are discussing how to safely implement it?
Manishearth commentedon Sep 5, 2015
I can't find it right now, but there already were some working scoped threads designs posted on the RfC. Not sure what the timeline for bringing this back is.
Manishearth commentedon Sep 5, 2015
rust-lang/rfcs#1084
bluss commentedon Sep 5, 2015
Crate crossbeam implements scoped threads.
Use crossbeam to get safety & stability.
antrik commentedon Oct 30, 2015
Guys, do you realise how ridiculous this looks? Let's see:
"Hi, I read about this amazing scoped threads feature in Rust, but... I can't actually find it? What's the deal?"
"Oh, that... The thing is... [wiggle squirm] We actually dropped it like half a year ago... But it's just temporary! We have ideas for a replacement! In fact, if you spend half a day wading through discussions on issues and pull requests, perhaps you will ultimately stumble upon a crate far away called Crossbeam that indeed implements a viable replacement, stuffed in along with various other experimental features... And surely something along these lines will someday somehow end up in the standard library again in some form (even though nothing actually seems to be happening regarding that right now)... So you see, it's all temporary! No need to even mention it in existing literature!"
"Riiiiiight.... [slowly backing away] You know, I think I'll actually look for some other language... But you kids keep having fun!"
Manishearth commentedon Oct 30, 2015
You don't need crossbeam. This is an old thread, the state of scoped threads has moved past this since then.
https://crates.io/crates/scoped_threadpool gives you the functionality. That's it. It's in an external crate which works and is sound, there's no pressing need to include it in the standard library.
steveklabnik commentedon Oct 30, 2015
@antrik please try to be a bit more substantial and less sarcastic with your criticism. This kind of comment isn't particularly welcome here.
antrik commentedon Oct 31, 2015
Pools are nice; yet crossbeam::Scope seems a more straightforward replacement for the old functionality?...
Anyway, debating this actually serves to demonstrate the existing confusion and lack of communication regarding this situation; creating an unacceptable story for any newcomer. thread::scoped() is prominently featured in a major piece of Rust advocacy (the mentioned blog post), without any hint that it's gone, or where to look for replacements; nor am I aware of any other clear communication regarding this, that people looking for thread::scoped() are likely to find -- and nobody seems to be willing to even acknowledge that there is a communication problem...
If my post wasn't substantial in illustrating how this feels to people outside the bubble, I really don't know what would be.
Manishearth commentedon Oct 31, 2015
Sure, that's a straightforward thing to propose. You could have just done that. Your initial comment didn't complain about the communication error, it just ranted unconstructively without anything really helpful.
@alexcrichton could you update the blog post with a note about scoped threads being moved out of the standard library to scoped_threadpool and Crossbeam?
Manishearth commentedon Oct 31, 2015
rust-lang/blog.rust-lang.org#74
antrik commentedon Oct 31, 2015
Thanks.
I was frustrated that the last person who suggested updating the post was brushed off, so I tried to illustrate why this is serious problem... Sorry that I failed to make my motivation clear.
Note though that updating this blog post only solves part of the problem. The Why Rust? "report" for example only vaguely hints at changes; and there might be other mentions out there as well -- so it would be helpful to have some kind of "landing page" for people looking for thread::scoped(). (Ideally right in the standard library documentation where it used to live -- though I guess that might be technically impossible after it has been dropped for good?...)
Manishearth commentedon Oct 31, 2015
We could add a dummy documentation page or something. Or just add a note in the thread module. Not sure what to do in this case, @steveklabnik
As for Why Rust I think the author was informed about this later, not sure if he changed anything.
steveklabnik commentedon Oct 31, 2015
I'm not aware of anyone being brushed off, but I think editing the post is a great idea. Merged.
I wouldn't be a fan of adding dummy doc pages.
Sent from my iPhone
jimblandy commentedon Oct 31, 2015
I'll update the Why Rust? report. (I used both scoped_threadpool and crossbeam::scope in my presentation at OSCON Amsterdam last week; they're great.)
(In the future, please feel free to contact me directly about these things, rather than just mention me obliquely!)