Skip to content

ICE when nesting managed pointers to a depth of 500 #5009

Closed
Closed
ICE when nesting managed pointers to a depth of 500#5009
Labels
A-type-systemArea: Type systemE-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.I-compiletimeIssue: Problems and improvements with respect to compile times.P-lowLow priority

Description

@bstrie
bstrie
opened on Feb 18, 2013
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.

Activity

  1. brson commented on Feb 18, 2013

    @brson
    brson
    on Feb 18, 2013
    Contributor

    This specific depth may be fixed by #3695

  2. nikomatsakis commented on Feb 20, 2013

    @nikomatsakis
    nikomatsakis
    on Feb 20, 2013
    Contributor

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

  3. bblum commented on Jun 17, 2013

    @bblum
    bblum
    on Jun 17, 2013
    Contributor

    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...

  4. bblum commented on Jun 17, 2013

    @bblum
    bblum
    on Jun 17, 2013
    Contributor

    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).

  5. emberian commented on Aug 5, 2013

    @emberian
    emberian
    on Aug 5, 2013
    Contributor

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

  6. emberian
    closed this as completedon Aug 5, 2013

  7. alexcrichton commented on Aug 5, 2013

    @alexcrichton
    alexcrichton
    on Aug 5, 2013
    Member

    This would probably be a good candidate for a test

  8. alexcrichton
    reopened this on Aug 5, 2013

  9. alexcrichton commented on Aug 13, 2013

    @alexcrichton
    alexcrichton
    on Aug 13, 2013
    Member

    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.

  10. pnkfelix commented on Feb 13, 2014

    @pnkfelix
    pnkfelix
    on Feb 13, 2014
    Contributor

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

  11. pnkfelix
    added
    P-low
    and removed
    P-high-untriaged
    on Feb 13, 2014

  12. pnkfelix commented on Feb 13, 2014

    @pnkfelix
    pnkfelix
    on Feb 13, 2014
    Contributor

    (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.)

  13. alexcrichton commented on Feb 13, 2014

    @alexcrichton
    alexcrichton
    on Feb 13, 2014
    Member

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

  14. alexcrichton
    removed
    E-needstest
    on Feb 13, 2014
  15. flaper87
    added
    E-needstest
    on Mar 12, 2014

  16. flaper87 commented on Mar 12, 2014

    @flaper87
    flaper87
    on Mar 12, 2014
    Contributor

    Flagged as needtest

    I confirm what's been said in the previous comments

  17. thestinger commented on Apr 1, 2014

    @thestinger
    thestinger
    on Apr 1, 2014
    Contributor

    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.

  18. thestinger
    closed this as completedon Apr 1, 2014
  19. bors
    added a commit that references this issue on May 2, 2020

    Auto merge of rust-lang#5009 - lzutao:travis-windows-msvc, r=phansch

    6271f56
  20. RalfJung
    added a commit that references this issue on May 12, 2026

    Merge pull request rust-lang#5009 from WhySoBad/network-socket-fix-sh…

    ffddc83
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-type-systemArea: Type systemE-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.I-compiletimeIssue: Problems and improvements with respect to compile times.P-lowLow priority

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions