Closed
Description
fn main() {
use std::{cell,gc,rc};
let a = rc::Rc::new(cell::RefCell::new( gc::Gc::new(1) ));
assert!(a.borrow().try_borrow_mut().is_some());
}
Expected output = none.
Actual output:
task '<main>' failed at 'assertion failed: a.borrow().try_borrow_mut().is_some()', test.rs:4
failed at 'assertion failed: self.live_allocs.is_null()', /mnt/code/claymore/rust/src/libstd/rt/local_heap.rs:138
Illegal instruction (core dumped)
Metadata
Metadata
Assignees
Labels
No labels
Activity
huonw commentedon Jan 14, 2014
This is almost certainly because
Gc
uses@
internally, andRc
can't handle that.emberian commentedon Jan 14, 2014
This just plain segfaults:
backtrace:
emberian commentedon Jan 14, 2014
(from this we can infer that a pointer somewhere is null. more likely, some data somewhere is of the wrong representation)
thestinger commentedon Jan 14, 2014
Supporting this isn't planned. This is part of replacing managed pointers with a real garbage collector. We were aware of the issue when the pull request for the new implementation of
Rc
was merged and decided to not fix it (although it didn't work before either).thestinger commentedon Jan 14, 2014
#10926 (comment) (most of the discussion was on IRC)
alexcrichton commentedon Jan 14, 2014
There's no way that we're releasing 1.0 without a better story here.
huonw commentedon Jan 14, 2014
This will be fixed with a GC like the one in #11399; although that may not land, and other designs could have this problem.
thestinger commentedon Jan 14, 2014
@alexcrichton: 1.0 isn't going to be released with these old managed pointers. This issue is not actionable because we agreed that adding complexity to support a feature that's on the way out makes no sense. There's no point in leaving an issue open if a pull request fixing it wouldn't be merged.
#2997 supersedes this issue.
kvark commentedon Jan 14, 2014
Did we ship 0.9 with that bug in? The elephant in the room here is not that managed pointers are not supported inside Rc, but the fact that one can waste multiple hours figuring out what's wrong should he happen to upgrade his code base from "@mut" to Gc/Rc. In fact, that's what happened to me, and nowhere did I notice a big fat warning that no Gc/'@' are allowed inside Rc, not even in This Week in Rust. There is no need to fix this, instead it would help to just put a proper compiler error/warning on that case until it gets properly resolved with the new Gc.
thestinger commentedon Jan 14, 2014
@kvark: This issue has been present long before 0.9. If you look at the pull request, you'll see that I originally added a
NonManaged
trait as a simple way of providing an error message without adding complexity to support both box headers on exchange allocations and spending the time debugging a separate take glue issue. It's not clear why exchange allocations need headers at all anyway when@T
is inside. It was never used for anything and won't be needed by a garbage collector. The whole thing is just not worth trying to support, and I'm not going to try to argue for including any more complexity to support it.This trait is not going to be necessary once the garbage collector is implemented, so #2997 is the real issue. We can stick an
#[experimental]
tag onGc<T>
if that would make people feel better. It will take a while to land a real garbage collector and then make it stable.kvark commentedon Jan 14, 2014
@thestinger Thanks for the explanation. I doubt marking Gc experimental is a good idea, because using Gc inside of Gc seems to work fine. Instead, marking Rc as experimental would provide a better protection. Meanwhile, using Gc instead of Rc is a temporary workaround, at least for me.
thestinger commentedon Jan 14, 2014
The
Gc<T>
type currently leaks cycles until tasks terminate which not really what you would expect... it's also broken with dozens of other functions in the standard library like theshrink_to_fit
method on unique vectors (#9510).There's not currently a reason to use it over
Rc<T>
, as it does far more reference counting, holds onto resources longer and doesn't have a way to do cyclical links without leaks likeWeak<T>
offers.std: Fix Rc with Gc inside of it
9 remaining items