Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stack overflow when compiling lots of macros #29466

Closed
ghost opened this issue Oct 30, 2015 · 7 comments · Fixed by #30044
Closed

Stack overflow when compiling lots of macros #29466

ghost opened this issue Oct 30, 2015 · 7 comments · Fixed by #30044
Assignees
Labels
A-MIR Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html P-high High priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@ghost
Copy link

ghost commented Oct 30, 2015

The code in this (large) gist causes a stack overflow using the current nightly (detailed below):

rustc 1.6.0-nightly (8ca0acc25 2015-10-28)
binary: rustc
commit-hash: 8ca0acc25adb00d29e52b015bded4b2872a1170c
commit-date: 2015-10-28
host: x86_64-unknown-linux-gnu
release: 1.6.0-nightly

This works as expected on stable and beta. On nightly, it prints the following:

thread 'rustc' has overflowed its stackSegmentation fault

gdb backtrace:

#0  0x00007ffff65338d6 in build::expr::as_operand::_$LT$impl$GT$::expr_as_operand::h9c1451c0620ac356CQa () from glibrustc_mir-8cf6ce90.so
#1  0x00007ffff6536c8b in build::expr::as_rvalue::_$LT$impl$GT$::expr_as_rvalue::h14d54ba4a836663bmCa () from glibrustc_mir-8cf6ce90.so
#2  0x00007ffff6540a32 in build::expr::into::_$LT$impl$GT$::into_expr::h6344e65068aab977g8a () from glibrustc_mir-8cf6ce90.so
#3  0x00007ffff6545dff in build::into::_$LT$impl$GT$::eval_into::h06f1417250413589Tob () from glibrustc_mir-8cf6ce90.so
#4  0x00007ffff6540fde in build::expr::into::_$LT$impl$GT$::into_expr::h6344e65068aab977g8a () from glibrustc_mir-8cf6ce90.so
#5  0x00007ffff6545dff in build::into::_$LT$impl$GT$::eval_into::h06f1417250413589Tob () from glibrustc_mir-8cf6ce90.so
#6  0x00007ffff65302ae in build::into::_$LT$impl$GT$::eval_into::he93472f166794e5e8pb () from glibrustc_mir-8cf6ce90.so
#7  0x00007ffff652e829 in build::block::_$LT$impl$GT$::ast_block::h2fd32d2e4e14cf99Wka () from glibrustc_mir-8cf6ce90.so
#8  0x00007ffff6542d81 in build::expr::into::_$LT$impl$GT$::into_expr::h6344e65068aab977g8a () from glibrustc_mir-8cf6ce90.so
#9  0x00007ffff6545dff in build::into::_$LT$impl$GT$::eval_into::h06f1417250413589Tob () from glibrustc_mir-8cf6ce90.so
#10 0x00007ffff6540fde in build::expr::into::_$LT$impl$GT$::into_expr::h6344e65068aab977g8a () from glibrustc_mir-8cf6ce90.so
#11 0x00007ffff6545dff in build::into::_$LT$impl$GT$::eval_into::h06f1417250413589Tob () from glibrustc_mir-8cf6ce90.so
#12 0x00007ffff6556421 in build::matches::_$LT$impl$GT$::expr_into_pattern::ha79c7de5a782ab45yUb () from glibrustc_mir-8cf6ce90.so
#13 0x00007ffff655c5f7 in build::stmt::_$LT$impl$GT$::stmt::h6613d503c10a36cdvSc () from glibrustc_mir-8cf6ce90.so
#14 0x00007ffff653018f in build::stmt::_$LT$impl$GT$::stmts::he98a9d97d5640b65RRc () from glibrustc_mir-8cf6ce90.so

... repeated a fair few times ...

#6497 0x00007ffff655dd5d in build::stmt::_$LT$impl$GT$::stmt::h6613d503c10a36cdvSc () from glibrustc_mir-8cf6ce90.so
#6498 0x00007ffff653018f in build::stmt::_$LT$impl$GT$::stmts::he98a9d97d5640b65RRc () from glibrustc_mir-8cf6ce90.so
#6499 0x00007ffff652e7ca in build::block::_$LT$impl$GT$::ast_block::h2fd32d2e4e14cf99Wka () from glibrustc_mir-8cf6ce90.so
#6500 0x00007ffff652a33e in build::construct::ha182b6bb92aa06f5Xba () from glibrustc_mir-8cf6ce90.so
#6501 0x00007ffff6562302 in mir_map::_$LT$impl$GT$::visit_fn::h9d61a6d7b3adc6e8a1c () from glibrustc_mir-8cf6ce90.so
#6502 0x00007ffff6560af9 in mir_map::_$LT$impl$GT$::visit_item::h6d489316c8636cd2aYc () from glibrustc_mir-8cf6ce90.so
#6503 0x00007ffff656004c in mir_map::build_mir_for_crate::hb6d45ba511f84ea1iWc () from glibrustc_mir-8cf6ce90.so
#6504 0x00007ffff7a525ad in driver::phase_3_run_analysis_passes::_$LT$closure$GT$::closure.21965 () from glibrustc_driver-8cf6ce90.so
#6505 0x00007ffff7a35d84 in middle::ty::context::_$LT$impl$GT$::create_and_enter::create_and_enter::h18093044235211963808 ()
   from glibrustc_driver-8cf6ce90.so
#6506 0x00007ffff7a30d7f in driver::phase_3_run_analysis_passes::h230269733980357556 () from glibrustc_driver-8cf6ce90.so
#6507 0x00007ffff7a117f3 in driver::compile_input::hc3d55c2eb88ab4bd8ba () from glibrustc_driver-8cf6ce90.so
#6508 0x00007ffff7b6851c in run_compiler::h0799634305b54a4dvqc () from glibrustc_driver-8cf6ce90.so
#6509 0x00007ffff7b65597 in sys_common::unwind::try::try_fn::try_fn::h9960778850285224810 () from glibrustc_driver-8cf6ce90.so
#6510 0x00007ffff757a739 in __rust_try () from glibstd-8cf6ce90.so
#6511 0x00007ffff756e78c in sys_common::unwind::try::inner_try::h39e356f8934d9b5cwds () from glibstd-8cf6ce90.so
#6512 0x00007ffff7b658e5 in boxed::_$LT$impl$GT$::call_box::call_box::h8909761637860690051 () from glibrustc_driver-8cf6ce90.so
#6513 0x00007ffff7581db4 in sys::thread::_$LT$impl$GT$::new::thread_start::h85eb4d682b5d5d4ffGw () from glibstd-8cf6ce90.so
#6514 0x00007ffff0c3f0a4 in start_thread (arg=0x7fffeebff700) at pthread_create.c:309
#6515 0x00007ffff720404d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
@Manishearth
Copy link
Member

Looks like we should be looping instead of recursing here?

cc @nrc

@durka
Copy link
Contributor

durka commented Nov 2, 2015

This is also a regression (the code compiles on stable and beta).

@nrc
Copy link
Member

nrc commented Nov 2, 2015

cc @nikomatsakis looks like a mir problem? I guess the macros thing is just a way to construct the problematic code?

@nikomatsakis
Copy link
Contributor

I agree this is caused by MIR construction. The macro seems kind of irrelevant.

@nikomatsakis
Copy link
Contributor

I think the cause is that each let introduces a new scope, and the MIR construction code recurses as we walk down those scopes. One possible fix would be to avoid recursion, but that might also be a bit tricky. Have to go look. Another option might be to employ the ability to grow the stack --- @alexcrichton you made some crate that lets you insert manual stack checks (and grow stack as needed), right? In general this might be a useful thing at various points in the compiler, where recursion can be so natural.

@nikomatsakis
Copy link
Contributor

@nikomatsakis nikomatsakis added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-MIR Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html labels Nov 4, 2015
@nikomatsakis
Copy link
Contributor

triage: P-high

This is a (Nightly-only) regression, so it's got to be fixed.

@rust-highfive rust-highfive added the P-high High priority label Nov 4, 2015
nikomatsakis added a commit to nikomatsakis/rust that referenced this issue Nov 25, 2015
bors added a commit that referenced this issue Nov 25, 2015
The graph extent mechanism is not good. I have some ideas for a better replacement, but this PR simply removes it. It also stops recursing on statement scopes and processes them using an "on the heap" stack, which fixes #29466.

r? @dotdash
steveklabnik added a commit to rust-lang/glacier that referenced this issue Nov 26, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-MIR Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html P-high High priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants