ICE when nesting managed pointers to a depth of 500

[bstrie]

fn main() {
    let foo =
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@1;
}

Hitting a recursion limit, perhaps?

$ RUST_LOG=rustc=1,::rt::backtrace rustc numtest.rs
rust: task b7606678 ran out of stack
/usr/local/bin/../lib/librustrt.so(_ZN9rust_task13begin_failureEPKcS1_j+0x5a)[0x1283ea]
/usr/local/bin/../lib/librustrt.so(rust_task_fail+0x36)[0x1284e6]
/usr/local/bin/../lib/librustrt.so(_ZN9rust_task4failEPKcS1_j+0x32)[0x128552]
/usr/local/bin/../lib/librustrt.so(_ZN9rust_task4failEv+0x35)[0x128595]
/usr/local/bin/../lib/librustrt.so(_ZN9rust_task9new_stackEj+0x153)[0x1286f3]
/usr/local/bin/../lib/librustrt.so(_Z14new_stack_slowP14new_stack_args+0x26)[0x128916]
/usr/local/bin/../lib/librustrt.so(+0x2935b)[0x13a35b]
/usr/local/bin/../lib/librustrt.so(upcall_new_stack+0x25e)[0x12b50e]
/usr/local/bin/../lib/librustc-c84825241471686d-0.6.so(+0x9423a3)[0x175f3a3]
/usr/local/bin/../lib/librustc-c84825241471686d-0.6.so(_ZN6middle6typeck5check23check_expr_with_unifier16_3d254a08f81dd713_06E+0x258a)[0x132297a]
/usr/local/bin/../lib/librustc-c84825241471686d-0.6.so(_ZN6middle6typeck5check23check_expr_with_unifier16_3d254a08f81dd713_06E+0x258a)[0x132297a]

((...this frame repeats a zillion times...))

/usr/local/bin/../lib/librustc-c84825241471686d-0.6.so(_ZN6middle6typeck5check23check_expr_with_unifier16_3d254a08f81dd713_06E+0x258a)[0x132297a]
/usr/local/bin/../lib/librustc-c84825241471686d-0.6.so(_ZN6middle6typeck5check23check_expr_with_unifier16_3d254a08f81dd713_06E+0x258a)[0x132297a]
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug
note: try running with RUST_LOG=rustc=1,::rt::backtrace to get further details and report the results to github.com/mozilla/rust/issues
rust: task failed at 'explicit failure', /root/catacombs/scrap/rust/src/librustc/rustc.rc:371
/usr/local/bin/../lib/librustrt.so(_ZN9rust_task13begin_failureEPKcS1_j+0x5a)[0x1283ea]
/usr/local/bin/../lib/librustrt.so(rust_task_fail+0x36)[0x1284e6]
/usr/local/bin/../lib/librustrt.so(_ZN9rust_task4failEPKcS1_j+0x32)[0x128552]
/usr/local/bin/../lib/librustrt.so(upcall_s_fail+0x53)[0x129eb3]
/usr/local/bin/../lib/librustrt.so(+0x2935b)[0x13a35b]
/usr/local/bin/../lib/librustrt.so(upcall_fail+0x1ae)[0x12ae3e]
/usr/local/bin/../lib/librustrt.so(rust_upcall_fail+0x2b)[0x12afab]
/usr/local/bin/../lib/libcore-c3ca5d77d81b46c1-0.6.so(_ZN3sys6rustrt16rust_upcall_fail17_2b2e25ba94c412183_06E+0x45)[0x6973b5]
/usr/local/bin/../lib/libcore-c3ca5d77d81b46c1-0.6.so(+0xf045b)[0x69745b]
/usr/local/bin/../lib/libcore-c3ca5d77d81b46c1-0.6.so(+0xf040d)[0x69740d]
/usr/local/bin/../lib/libcore-c3ca5d77d81b46c1-0.6.so(_ZN3sys12begin_unwind17_7cd364c41f10422f3_06E+0x73)[0x5dbee3]
/usr/local/bin/../lib/libcore-c3ca5d77d81b46c1-0.6.so(+0x12421c)[0x6cb21c]
/usr/local/bin/../lib/librustc-c84825241471686d-0.6.so(_ZN7monitor17_e3f3c07a24a8bc503_06E+0x69bd)[0x175109d]
/usr/local/bin/../lib/librustc-c84825241471686d-0.6.so(+0x9423b8)[0x175f3b8]
/usr/local/bin/../lib/librustc-c84825241471686d-0.6.so(_ZN4main16_706f4ee7413ae583_06E+0x7e)[0x175f02e]
rustc(_rust_main+0x31)[0x8048961]
/usr/local/bin/../lib/librustrt.so(_Z18task_start_wrapperP10spawn_args+0x31)[0x129521]
rust: domain main @0x8c5a388 root task failed

Yeah, this is silly.

[brson]

This specific depth may be fixed by #3695

[nikomatsakis]

I think the "bug" here is basically OOM, no? I mean our stacks currently have no defined upper limit on their size? (@brson?)

[bblum]

Tried this with haskell, with a type data X a = X a. It appears to be able to handle both typechecking and evaluation, although it gets seriously slow and takes multiple gigs of RAM at the 1024 nesting depth. I didn't bother to measure the asymptotic nature of the growth.

But, I think it'd be ok to impose an arbitrary limit on type structure depth. The hard question there would be how can we know what the depth is...

[bblum]

SML/NJ is actually quite fast, and can handle 8000+ nesting depth with O(1) memory consumption, although it seems to take superlinear time.

Using ghc instead of ghci appears to work for 1000+, although I have to set the -fcontext-stack option to much bigger than the default of 200 (i used 6400).

[emberian]

This no longer ICEs, at least for me. Closing.

[alexcrichton]

This would probably be a good candidate for a test

[alexcrichton]

Actually, when compiling this with -O, this program causes rustc to consume > 2G of ram. Even though it's a bit of an absurd test, the compiler probably shouldn't be taking up gigs of ram and this may be an indication of a deeper problem. Also, the compile time is 2 minutes.

Removing the needstest tag.

[pnkfelix]

@alexcrichton just said this now works. Flagging as needstest and assigning P-low.

[pnkfelix]

(Also, the test now passes in part because the threshold for stack exhaustion has increased; using 2500 instead of 500 causes rustc to blow its stack.)

[alexcrichton]

Note that going deeper to something like 2500 @ sigils causes rustc to overflow its stack. This is somewhat reasonable perhaps...

[flaper87]

Flagged as needtest

I confirm what's been said in the previous comments

[thestinger]

A test for this specific issue is unnecessary because managed pointers are being removed, so it would be counter-productive to start adding new tests for the feature. A new example of this issue with a non-deprecated type would be worthy of a new issue.