Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Call to vec::filter causes segfault in rustdoc tests #4439

Closed
catamorphism opened this Issue Jan 11, 2013 · 9 comments

Comments

Projects
None yet
5 participants
Contributor

catamorphism commented Jan 11, 2013

Rustdoc tests were segfaulting -- I narrowed down the problem to the call to vec::filter in prune_private_pass::fold_mod. When I changed that to filtered, the segfault went away. Sorry, I don't have a more minimal test case at this point.

@erickt , you may be interested (though the bug is likely in trans and not your fault).

Contributor

Dretch commented Jan 25, 2013

Perhaps related: this code compiles ok but segfaults when run, for me at least:

fn main() {
    let _ = (~[1]).filter(|_| true);
}

It seems like calls to ~[T].filter always fail. Using vec::filter instead of the method seems to work ok.

Contributor

catamorphism commented Mar 25, 2013

I wonder if this is also related to #4850 and/or #4759

Contributor

catamorphism commented Mar 25, 2013

I think the original bug that I reported is a non-issue now, because borrowck now rejects the code with filter instead of filtered.

I'll check @Dretch 's example, but my guess is borrowck will reject it too.

Contributor

catamorphism commented Mar 25, 2013

No, @Dretch 's example still segfaults. There goes that theory!

Contributor

catamorphism commented Mar 25, 2013

I think the following simpler example captures both what's going wrong here, and in #4850:

trait Eat {
    fn f(self);
}

impl Eat for ~int {
    fn f(self) {
        fail_unless!((*self) == 42);
    }
}

fn main() {
  (~42).f();
}

@catamorphism catamorphism was assigned Apr 1, 2013

Contributor

catamorphism commented Apr 1, 2013

I'm working on this, but don't know if I can get it done for 0.6

Contributor

erickt commented Apr 14, 2013

@catamorphism: Any luck tracking this down? I dug into it a bit tonight, and I've gotten as far as determining that both the self-by-value method and the scope that owns the object are calling the drop functionality, but I haven't yet figured out how the callee is supposed to know it shouldn't emit the drop glue. The liveness checker seems to be aware that ownership transferred into the method, but trans is still queuing up the unique pointer for cleanup.

Contributor

catamorphism commented Apr 14, 2013

@erickt It's a trans bug. The way trans does by-value/by-move self is just horribly wrong and inconsistent. I couldn't see an easy fix -- I wanted to rewrite all the self code to use Datum, so as to make it more obvious what was going wrong, but didn't have time.

Alternately, @nikomatsakis had some ideas about making the code (in trans and elsewhere) that deals with self more uniform, which might also expose the bug more clearly.

Feel free to work on it, I don't have time to in the immediate future but am happy to try to answer questions.

Contributor

indutny commented May 23, 2013

subscribing

@bors bors added a commit that referenced this issue Jun 28, 2013

@bors bors auto merge of #7410 : luqmana/rust/bare-self, r=catamorphism
Finally sorted this out. Fixes #5321, #4439, and #4850.
61dc776

@luqmana luqmana closed this Jun 28, 2013

@catamorphism catamorphism removed their assignment Jun 16, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment