core dump: fn pointer in iterator

[phildawes]

Hello! The following dumps core when run on my machine (Ubuntu 12.04 LTS, rust-nightly downloaded today (18th Apr)). Ziad Hatahet confirmed the same on a slightly older version of rust.

struct StateMachineIter<'a> {
    statefn: &'a fn(&mut StateMachineIter<'a>) -> Option<&'static str>
}

impl<'a> Iterator<&'static str> for StateMachineIter<'a> {
    fn next(&mut self) -> Option<&'static str> {
        return  (*self.statefn)(self);
    }
}

fn state1(self_: &mut StateMachineIter) -> Option<&'static str> {
    self_.statefn = &state2;
    return Some("state1");
}

fn state2(self_: &mut StateMachineIter) -> Option<(&'static str)> {
    self_.statefn = &state3;
    return Some("state2");
}

fn state3(self_: &mut StateMachineIter) -> Option<(&'static str)> {
    self_.statefn = &finished;
    return Some("state3");
}

fn finished(_: &mut StateMachineIter) -> Option<(&'static str)> {
    return None;
}

fn state_iter() -> StateMachineIter {
    StateMachineIter { statefn: &state1 }
}


fn main() {
    let mut it = state_iter();
    println!("{}",it.next());
    println!("{}",it.next());
    println!("{}",it.next());
    println!("{}",it.next());
    println!("{}",it.next());
}

[sfackler]

There's an extra layer of indirection in that struct definition. A &'a fn() is a pointer to a pointer to a function. A statement like self_.statefn = &finished; expands to let foo = finished; self_.statefn = &foo. That's obviously creating a dangling pointer onto the stack which is why it ends up crashing. Adjusting the struct definition to

struct StateMachineIter {
    statefn: fn(&mut StateMachineIter) -> Option<&'static str>
}

should make things work as you want. There's also a bug in rustc for even letting that program compile. I'm not sure if it's already been run into and filed.

[alexcrichton]

cc @nikomatsakis

[edwardw]

This fixes it:

...
fn finished(self_: &mut StateMachineIter) -> Option<(&'static str)> {
    self_.statefn = &finished;
    return None;
}
...

But I didn't quite understand why.

[sfackler]

@edwardw it probably happens to reset that part of the stack to the right value.

[artella-coding]

@alexcrichton @nikomatsakis @huonw p.s. This is still crashing in rustc 0.12.0-pre-nightly (f50e4ee559c0e6253e9d46a8e6763e25f7b90d90 2014-07-18 00:01:22 +0000). Thanks

[alexcrichton]

Nominating, something fishy is going on here.

[zwarich]

Here's the simplest possible reduction I could make:

struct A<'a> {
    func: &'a fn() -> Option<int>
}

impl<'a> A<'a> {
    fn call(&self) -> Option<int> {
        (*self.func)()
    }
}

fn foo() -> Option<int> {
    None
}

fn create() -> A<'static> {
    A { func: &foo }
}

fn main() {
    let a = create();
    a.call();
}

[huonw]

Is the compiler mixing up the function pointer with the actual function code?

That is,

fn foo() {}

fn main() { let x = foo; }

is like

static foo_code: [u8, .. N] = [/*machine code*/];

fn main() { let x = &foo_code; } // *not* let x = foo_code;

So writing &foo is like &(&foo_code), i.e. a non-'static reference to the 'static function pointer.

[zwarich]

@huonw It's just creating an alloca, storing the function pointer into it, borrowing that, and returning the borrowed pointer. For example, on the program

fn foo() { }

fn bar() -> &'static fn() {
    &'static foo
}

I get this LLVM IR:

define internal void @_ZN3foo20h98be24cee3d646d9eaa4v0.0E() unnamed_addr #0 {
entry-block:
  ret void
}

define internal nonnull void ()** @_ZN3bar20hb2bd4683ab9952d6haa4v0.0E() unnamed_addr #0 {
entry-block:
  %addr_of = alloca void ()*
  store void ()* @_ZN3foo20h98be24cee3d646d9eaa4v0.0E, void ()** %addr_of
  ret void ()** %addr_of
}

Basically, the borrow checker doesn't seem to be in on the joke that &foo is referring to a local alloca.

[huonw]

That is the behaviour I would expect if my statement were true. (The double ** in the LLVM signature indicates what I was talking about: a function value foo is already the 'static pointer, and so the foo name doesn't have 'static lifetime.)

[brson]

1.0 backcompat-lang

[nikomatsakis]

This is probably a mismatch between trans/mem-categorization. I expect mem-categorization is saying that the "reference to the fn" is a static item, but trans is translating it into an rvalue (and hence on the stack).