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

cast to &Trait causes code to segfault on method call #5008

Closed
mitsuhiko opened this issue Feb 18, 2013 · 9 comments
Closed

cast to &Trait causes code to segfault on method call #5008

mitsuhiko opened this issue Feb 18, 2013 · 9 comments
Labels
E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.

Comments

@mitsuhiko
Copy link
Contributor

trait Debuggable {
    fn debug_name(&self) -> ~str;
}

struct Thing {
    name: ~str,
}

impl Thing {
    static pure fn new() -> Thing { Thing { name: ~"dummy" } }
}

impl Debuggable for Thing {
    fn debug_name(&self) -> ~str { copy self.name }
}

fn print_name(x: &Debuggable)
{
    io::println(fmt!("debug_name = %s", x.debug_name()));
}

fn main() {
    let thing = Thing::new();
    print_name(thing as &Debuggable);
}

This code segfaults with this traceback:

#0  0x0000000100000e4b in glue_take_1991 ()
#1  0x0000000100414680 in ?? ()
#2  0x0000000100000e03 in __extensions__::meth_1987::debug_name::_8b22bed097777cf7::_00 ()
#3  0x000000010000113c in print_name::_e4762c9c8d3caa0::_00 ()
#4  0x0000000100001a49 in __morestack ()
#5  0x000000010000106c in print_name::_e4762c9c8d3caa0::_00 ()
#6  0x00000001000016ee in _rust_main ()
#7  0x00000001002e4805 in task_start_wrapper (a=0x10081c628) at rust_task.cpp:162

It fixes itself if the &Trait is changed to @Trait.

@mitsuhiko
Copy link
Contributor Author

Fun fact: the copy self.name causes this problem. If you return a ~"foo" instead the code works.

@14427
Copy link
Contributor

14427 commented Feb 19, 2013

Possibly related to #4333?

@ghost ghost assigned catamorphism Feb 21, 2013
@nikomatsakis
Copy link
Contributor

Not critical for 0.6; removing milestone

@pnkfelix
Copy link
Member

The code does not compile for me, by the way; I get the following error from rustc:

/tmp/bar.rs:24:15: 24:35 error: can only cast an &-pointer to an &-object, not a struct Thing
/tmp/bar.rs:24     print_name(thing as &Debuggable);
                              ^~~~~~~~~~~~~~~~~~~~

@DoctorAlpaca
Copy link

Probably related; this results in a segfault:

struct Foo {
    x: int
}
struct Bar {
    x: float
}
trait Tra {
    fn get_value(&self) -> int;
}
impl Tra for Foo {
    fn get_value(&self) -> int {
        self.x
    }
}
impl Tra for Bar {
    fn get_value(&self) -> int {
        self.x as int
    }
}

fn test(a: &~Tra) -> int {
    a.get_value()
}

fn main() {
    let list = ~[~Foo{x: 3} as ~Tra, ~Bar{x: 5.3} as ~Tra];
    let mapped = list.map(test);
    io::println(fmt!("%?", mapped));
}

Switching from owned to managed boxes removes the crash.

@pnkfelix
Copy link
Member

I vaguely recall from this meeting that we are going to remove "as ~Trait"; it seems like that might "address" the note from @thatfreakingguy (unless the analogous assignability-code also crashes).

In any case, I worry that the two issues are actually orthogonal; lets not conflate them prematurely. (That is, I'd like to keep the focus of the discussion on @mitsuhiko's original report, unless someone can provide concrete evidence that the two issues are related.)

Also, I do not want to nominate this bug for a maturity milestone nor close it until I determine what the current status of the original test is. (Last I checked, rustc flagged it as erroneous; that's one reason why I am saying I am not convinced it is related to the note from @thatfreakingguy.) It could be that the code needs to be massaged slightly to get past rustc's checks, or it could be that there was a fundamental problem in it that rustc is now rightfully flagging. I just don't know, yet.

@emberian
Copy link
Member

emberian commented Jul 3, 2013

Trying to reproduce on current master a bit fruitless. I got this far:

trait Debuggable {
    fn debug_name(&self) -> ~str;
}

struct Thing {
    name: ~str,
}

impl Thing {
    fn new() -> Thing { Thing { name: ~"dummy" } }
}

impl Debuggable for Thing {
    fn debug_name(&self) -> ~str { copy self.name }
}

fn print_name(x: &Debuggable) {
    println(fmt!("debug_name = %s", x.debug_name()));
}

fn main() {
    let thing = Thing::new();
    print_name(&thing as &Debuggable);
}

which yields

foo.rs:23:15: 23:21 error: borrowed value does not live long enough
foo.rs:23     print_name(&thing as &Debuggable);
                         ^~~~~~
note: borrowed pointer must be valid for the static lifetime...
foo.rs:21:10: 24:1 note: ...but borrowed value is only valid for the block at 21:10
foo.rs:21 fn main() {
foo.rs:22     let thing = Thing::new();
foo.rs:23     print_name(&thing as &Debuggable);
foo.rs:24 }
error: aborting due to previous error

@sammykim
Copy link
Contributor

Example 1

trait Debuggable {
    fn debug_name(&self) -> ~str;
}

#[deriving(Clone)]
struct Thing {
name: ~str,
}

impl Thing {
    fn new() -> Thing { Thing { name: ~"dummy" } }
}

impl Debuggable for Thing {
    fn debug_name(&self) -> ~str { self.name.clone() }
}

fn print_name(x: &Debuggable)
{
    println(fmt!("debug_name = %s", x.debug_name()));
}

fn main() {
    let thing = Thing::new();
    print_name(&thing as &Debuggable);
}

I guess it isn't an issue anymore. Any opinions?

@alexcrichton
Copy link
Member

Huzzah! Flagging as needstest

huonw added a commit to huonw/rust that referenced this issue Sep 16, 2013
bors added a commit that referenced this issue Sep 16, 2013
bors added a commit that referenced this issue Sep 17, 2013
@huonw huonw closed this as completed in 4f92f45 Sep 17, 2013
bors added a commit to rust-lang-ci/rust that referenced this issue May 2, 2020
Do not trigger `let_and_return` lint on macros

Fixes rust-lang#4997

changelog: Fix false positive in `let_and_return`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants