Skip to content

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

New issue

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

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants