Skip to content

Process exited with signal 11 when mutable array of usize created #31748

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
vyskocilm opened this issue Feb 18, 2016 · 4 comments
Closed

Process exited with signal 11 when mutable array of usize created #31748

vyskocilm opened this issue Feb 18, 2016 · 4 comments

Comments

@vyskocilm
Copy link

The testcase

type Grid = [[usize; 1000]; 1000];

#[test]
fn test () {
    let mut grid : Grid = [[0; 1000]; 1000];
}

fn main() {
}
 cargo test
   Compiling sig11 v0.1.0 (file:///home/mvyskocil/bordel/adventofcode/sig11)
src/main.rs:6:9: 6:17 warning: unused variable: `grid`, #[warn(unused_variables)] on by default
src/main.rs:6     let mut grid : Grid = [[0; 1000]; 1000];
                      ^~~~~~~~
src/main.rs:6:9: 6:17 warning: variable does not need to be mutable, #[warn(unused_mut)] on by default
src/main.rs:6     let mut grid : Grid = [[0; 1000]; 1000];
                      ^~~~~~~~
     Running target/debug/sig11-3533bb6cb3c1d616

running 1 test
Process didn't exit successfully: `/home/mvyskocil/bordel/adventofcode/sig11/target/debug/sig11-3533bb6cb3c1d616` (signal: 11)
/usr/local/bin/rustc --version --verbose
rustc 1.7.0-beta.3 (36237fc61 2016-02-11)
binary: rustc
commit-hash: 36237fc61221418125e6ab91b135d4e174750fa3
commit-date: 2016-02-11
host: x86_64-unknown-linux-gnu
release: 1.7.0-beta.3

This is an output of lldb

lldb target/debug/sig11-3533bb6cb3c1d616 
Current executable set to 'target/debug/sig11-3533bb6cb3c1d616' (x86_64).
(lldb) bt
error: invalid process
(lldb) run
Process 5895 launching
Process 5895 launched: '/home/mvyskocil/bordel/adventofcode/sig11/target/debug/sig11-3533bb6cb3c1d616' (x86_64)
Process 5895 stopped
* thread #1: tid = 5895, 0x00007fca21ce9190, name = 'sig11-3533bb6cb'
    frame #0: 

running 1 test
Process 5895 stopped
* thread #3: tid = 5900, 0x00007fca21f18dab sig11-3533bb6cb3c1d616`sig11::test + 43 at main.rs:5, name = 'test', stop reason = address access protected (fault address: 0x7fca1fe5baa8)
    frame #0: 0x00007fca21f18dab sig11-3533bb6cb3c1d616`sig11::test + 43 at main.rs:5
   2    type Grid = [[usize; 1000]; 1000];
   3    
   4    #[test]
-> 5    fn test () {
   6        let mut grid : Grid = [[0; 1000]; 1000];
   7    }
   8    
(lldb) bt
* thread #3: tid = 5900, 0x00007fca21f18dab sig11-3533bb6cb3c1d616`sig11::test + 43 at main.rs:5, name = 'test', stop reason = address access protected (fault address: 0x7fca1fe5baa8)
  * frame #0: 0x00007fca21f18dab sig11-3533bb6cb3c1d616`sig11::test + 43 at main.rs:5
    frame #1: 0x00007fca21f377a7 sig11-3533bb6cb3c1d616`boxed::F.FnBox$LT$A$GT$::call_box::h15856693885952690269 + 23
    frame #2: 0x00007fca21f3a11c sig11-3533bb6cb3c1d616`sys_common::unwind::try::try_fn::h11859028028709367878 + 412
    frame #3: 0x00007fca21f5e879 sig11-3533bb6cb3c1d616`__rust_try + 9
    frame #4: 0x00007fca21f5b75c sig11-3533bb6cb3c1d616`sys_common::unwind::try::inner_try::h7232ca0b9dac160cJ8s + 108
    frame #5: 0x00007fca21f3a49b sig11-3533bb6cb3c1d616`boxed::F.FnBox$LT$A$GT$::call_box::h5923360345989389816 + 315
    frame #6: 0x00007fca21f601e4 sig11-3533bb6cb3c1d616`sys::thread::Thread::new::thread_start::h93f164b37c9b35e1Ctx + 132
    frame #7: 0x00007fca218cf0a4 libpthread.so.0`start_thread(arg=0x00007fca205ff700) + 196 at pthread_create.c:309
    frame #8: 0x00007fca213ee08d libc.so.6`__clone + 109
(lldb) 
@vyskocilm
Copy link
Author

I've tested several basic types (isize, u32, i64, char, ...), but it fails all the time with segfault. The only one form, which I found working well is array of bools.

@mitaa
Copy link
Contributor

mitaa commented Feb 18, 2016

Related to #31273, #31333, #31457

@retep998
Copy link
Member

1000*1000 is nearly a MB. I believe the default stack for new threads in Rust is 2MB although Rust doesn't control the stack size for the main thread. This is simply a stack overflow.

@alexcrichton
Copy link
Member

Ah yes this just looks like a standard case of stack overflow. The guard page is getting completely skipped over here which is why you're not getting the standard stack overflow message as well. As a result this is largely just a dupe of #16012, so I'm going to close this in favor of that.

Thanks for the report though!

# 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

4 participants