stack overflow in rust-brotli

[nikomatsakis]

This commit in rust-brotli:

dropbox/rust-brotli@e580fea

fixes a stack overflow that started occurring recently with nightly builds. Perhaps related to #35408?

@danielrh, do you always test against the most recent nightly, or do you only upgrade nightly periodically? I am trying to narrow down when this stack overflow may have started to occur.

[danielrh]

I got distracted for several months, so this test had not been running since early July

[TimNN]

I get the stack overflow also onrustc 1.12.0-beta.6 (on OS X)

[TimNN]

I can reproduce this as early as nightly-2016-03-20 with RUSTFLAGS="-Z orbit" (the nightly before, nightly-2016-03-20, does not support -Z orbit).

Also seems to be related to mir since on eg. nightly-2016-08-16 it reproduces with -Z orbit but not with -Z orbit=off.

[nikomatsakis]

@TimNN thanks =) I am hoping that this proves to be a slightly more tractable use case to analyze and improve the stack usage problems we found in #35408. (Though current theory is that the best way to fix is general purpose MIR optimizations.)

cc @eddyb

[eddyb]

cc @pcwalton

[khernyo]

I bumped into this too: https://travis-ci.org/khernyo/zopfli-rs/jobs/98794028
Source is at https://github.com/khernyo/zopfli-rs if it helps.

[khernyo]

You can find a minimized version at https://github.com/khernyo/rust-issue-36778

Basically it boils down to the following code, but the stack overflow only manifests when it's run using cargo run:

fn main() {
    let child = std::thread::spawn(|| {
        std::cell::RefCell::new([0i8; 232500]);
    });
    child.join().unwrap();
}

The first rust commit which seems to causes the stack overflow is ee977e7

[eddyb]

Yeah that's MIR alright - if you double the array size it also breaks before the switch to MIR, right?

[khernyo]

Yes, that's right.