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

Segmentation fault due to iterator living longer than its parent #13929

Closed
hatahet opened this issue May 4, 2014 · 1 comment
Closed

Segmentation fault due to iterator living longer than its parent #13929

hatahet opened this issue May 4, 2014 · 1 comment

Comments

@hatahet
Copy link
Contributor

hatahet commented May 4, 2014

This bug was originally reported on the Rust subreddit by user double_to_bool_conv: http://www.reddit.com/r/rust/comments/24kfmv/iterator_can_live_longer_than_its_parent_is_this/

The version below has been updated after the removal of the ~"string" syntax.

$ rustc -v
rustc 0.11-pre (4f1b0b5 2014-05-03 12:21:47 -0700)
host: x86_64-unknown-linux-gnu

n owned_iterator(slice: &[~str]) -> ~Iterator<~str> {
    ~slice.iter().map(|s| s.clone()) as ~Iterator<~str>
}

fn main() {
    let mut fail = {
        owned_iterator(~["ok".to_owned()])
    };
    let v = ~["fail".to_owned()];
    for i in fail {
        println!("{}", i); // prints "fail"
    }

    let mut segFault = {
        owned_iterator(~["ok".to_owned()])
    };
    let v = ~[-1];
    for i in segFault {
        println!("{}", i); // Segmentation fault 
    }
}
@alexcrichton
Copy link
Member

Closing as a dupe of #9745, which is itself claimed to be a dupe of #5723. Thanks for the report though!

bors added a commit to rust-lang-ci/rust that referenced this issue Feb 13, 2023
internal: a number of code simplifications
bors pushed a commit to rust-lang-ci/rust that referenced this issue Jan 28, 2025
…ang#13929)

Some lifetimes in function return types are not bound to concrete
content and can be set arbitrarily. Clippy should not propose to replace
them by the default `'_` lifetime if such a lifetime cannot be
determined unambigously.

I added a field to the `LifetimeChecker` and `Usage` to flag lifetimes
that cannot be replaced by default ones, but it feels a bit hacky.

Fix rust-lang#13923

changelog: [`needless_lifetimes`]: remove false positives by checking
that lifetimes can indeed be elided
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants