Huge stack arrays cause stack overflow with segmentation fault

[dns2utf8]

I noticed a 4MB stack allocated buffer within a thread causes the thread to panic.
In the main it takes 8MB to crash on amd64: Run on play

The strange part is, even when I box it, it still segfaults: Run on Play

Am I using the Box wrong? Why does it SEGV at all? In my understanding allocating 8MB at once is not such a big deal anymore.

[bstrie]

The ability to guarantee in-place heap construction is tracked by #27779 , and the ability to guarantee that real stack overflows properly abort (rather than segfault) is blocked by #16012 .

[dns2utf8]

Well this is very unfortunate. But how does this affect boxed values like Box::new( [0u8, 1 << 24] )?

[shepmaster]

But how does this affect boxed values like

In debug mode, the array is still built on the stack, then moved to the Box. That's what @bstrie means by "guarantee in-place heap construction" — if that was present, there should be a way to guarantee that the array is never placed on the stack.

In release mode, I think this will sometimes correctly avoid the stack allocation.

In the mean time, you are encouraged to use into_boxed_slice (playground):

fn main() {
    vec![0u8; 1 << 24].into_boxed_slice();
}

[shepmaster]

I noticed a 4MB stack allocated buffer within a thread causes the thread to panic. In the main it takes 8MB to crash

From a relevant Stack Overflow question:

The default stack size of the main thread is typically 8 MiB, so that array is going to occupy half of the available stack. That's a lot, but there's still room available, so the benchmark runs normally.

The stack size of a new thread, however, is typically much smaller. On Linux it is 2 MiB, and other platforms could be even smaller. So, your 4 MiB array easily overflows the thread's stack and causes a stack overflow / segfault.

[alexcrichton]

I believe this has since been fixed now that stack probes are implemented, so closing.