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

"task ... ran out of stack" error #6049

Closed
skinner opened this issue Apr 24, 2013 · 5 comments
Closed

"task ... ran out of stack" error #6049

skinner opened this issue Apr 24, 2013 · 5 comments

Comments

@skinner
Copy link

skinner commented Apr 24, 2013

I get a "task .. ran out of stack" error with this program:

use core::hashmap::HashMap;

fn main() {
    let mut map : HashMap<~str, int> = HashMap::new();
    let keys = ~[~"foo", ~"bar", ~"foo"];
    do keys.consume |_, key| {
        let count;
        {
            let count_option = map.find(&key);
            match count_option {
                Some(x) => { count = *x; },
                None => { count = 0; }
            }
        }
        map.insert(key, count + 1);
    }

    for map.each |&key, &count| {
        println(fmt!("%?: %?", key, count));
    }
}

I was originally trying to work around the lack of flow-sensitivity in borrowck, so the code is a little contorted from what would be natural. But I imagine that the "out of stack" error is a separate issue.

rustc is:
rustc 0.6 (ee3789b 2013-04-24 13:33:29 -0700)
host: x86_64-unknown-linux-gnu

running on Fedora 17.

@kud1ing
Copy link

kud1ing commented Apr 25, 2013

rustsqlite's unit test tests::step_row_basics recently has a similar error with rust incoming:

rust: task 7fb9a14107e0 ran out of stack

@skinner
Copy link
Author

skinner commented Apr 26, 2013

Okay, I reproduced this on a different machine (also fedora 17 x86_64), and I cut the test case down. I'm a little surprised by how simple it ended up being:

use core::hashmap::HashMap;

fn main() {
    let mut map : HashMap<~str, int> = HashMap::new();
    map.insert(~"foo", 1);
}

I ran gdb on it; I set a breakpoint in rust_task::fail per pcwalton's suggestion. The backtrace from there contains a few hundred thousand calls to rand::next, but I went all the way to the bottom of the backtrace, and this is what it looks like:

#283966 0x0000000000405db5 in rand::__extensions__::next_2755::_90bd14656eb73ce::_00 ()
#283967 0x0000000000405db5 in rand::__extensions__::next_2755::_90bd14656eb73ce::_00 ()
#283968 0x0000000000405db5 in rand::__extensions__::next_2755::_90bd14656eb73ce::_00 ()
#283969 0x0000000000405d31 in rand::__extensions__::rand_2752::_da34413e5895a8b::_00 ()
#283970 0x0000000000405cd3 in rand::__extensions__::gen_2749::_67c43c75b977a99f::_00 ()
#283971 0x0000000000403aa9 in hashmap::linear_map_with_capacity_2584::_e74c518b1fb540de::_00 ()
#283972 0x0000000000403a3a in hashmap::__extensions__::with_capacity_2581::_e74c518b1fb540de::_00 ()
#283973 0x00000000004039d3 in hashmap::__extensions__::new_2578::_b4139432f8d437b0::_00 ()
#283974 0x00000000004037c6 in main::_28d936a8bfce3ea3::_00 ()
#283975 0x00000000004038f4 in _rust_main ()
#283976 0x00007ffff78343d4 in task_start_wrapper (a=0x61e060) at /home/mitch/sw/rust/src/rt/rust_task.cpp:163
#283977 0x0000000000000000 in ?? ()

rustc for this is a slightly newer version from incoming:

rustc 0.6 (0604468 2013-04-25 12:42:41 -0700)
host: x86_64-unknown-linux-gnu

@gifnksm
Copy link
Contributor

gifnksm commented Apr 28, 2013

I also reproduce this. My test case is almost the same as skinner's.

use core::hashmap::{ HashMap };

fn main() {
  let mut map = HashMap::new();
  map.insert(1u, 1u);
}

HashMap::new calls IsaacRng#gen(), and following code causes stack overflow.

use core::rand::{ IsaacRng, RngUtil };

fn main() {
  let r = @IsaacRng::new();
  io::println(fmt!("%u", r.gen()));
}

But following code doesn't cause stack overflow (@IsaacRng vs IsaacRng).

use core::rand::{ IsaacRng, RngUtil };

fn main() {
  let r = IsaacRng::new();
  io::println(fmt!("%u", r.gen()));
}

My machine information is below.

$ rustc --version
rustc 0.6 (5f7947a 2013-04-27 19:18:33 -0700)
host: x86_64-unknown-linux-gnu
$ ulimit -s
8192
$ uname -a
Linux arch-vbox 3.8.4-1-ARCH #1 SMP PREEMPT Wed Mar 20 22:10:25 CET 2013 x86_64 GNU/Linux

@pnkfelix
Copy link
Member

See also #6061

@skinner
Copy link
Author

skinner commented Apr 28, 2013

I'm not seeing the "ran out of stack" error anymore with incoming, so I think I'll close this issue. There may still be a problem, per @pnkfelix's comments on #6061, but maybe that should be a separate issue?

@skinner skinner closed this as completed Apr 28, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Sep 24, 2020
Fix clippy hard-code slice::Iter path

r? `@ghost`

changelog: none
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

4 participants