Skip to content
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

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

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

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

catamorphism opened this issue Jan 11, 2013 · 9 comments
Labels
A-lifetimes Area: lifetime related I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.

Comments

@catamorphism
Copy link
Contributor

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).

@Dretch
Copy link
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.

@catamorphism
Copy link
Contributor Author

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

@catamorphism
Copy link
Contributor Author

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.

@catamorphism
Copy link
Contributor Author

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

@catamorphism
Copy link
Contributor Author

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();
}

@ghost ghost assigned catamorphism Apr 1, 2013
@catamorphism
Copy link
Contributor Author

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

@erickt
Copy link
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.

@catamorphism
Copy link
Contributor Author

@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.

@indutny
Copy link
Contributor

indutny commented May 23, 2013

subscribing

bors added a commit that referenced this issue Jun 28, 2013
@luqmana luqmana closed this as completed 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
Labels
A-lifetimes Area: lifetime related I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
Projects
None yet
Development

No branches or pull requests

5 participants