Skip to content

thread 'rustc' has overflowed its stack #72933

Closed
@avl

Description

@avl

I just tried the latest nightly (rustc 1.45.0-nightly (ad4bc33 2020-06-01)) and noticed it can't compile one of the crates I work on.

The crate does have an enum with a a huge number of variants (almost 6000), for which I use serde to derive Serialize and Deserialize.

When building, even with just 'cargo check', the build fails with

thread 'rustc' has overflowed its stack
fatal runtime error: stack overflow
error: could not compile `<crate_name>`.

It works on stable 1.43.1.

I tried running rustc under gdb. It didn't crash exactly the same way, I got SIGSEGV instead.

Looking at the callstack in gdb, it is suspiciously deep (15000 functions deep). The top most functions are:

#0  0x00007ff0bae9925b in rustc_mir_build::build::matches::simplify::<impl rustc_mir_build::build::Builder>::simplify_candidate ()
   from /home/anders/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-b6bcd19e02bce685.so
#1  0x00007ff0bae9e7ad in rustc_mir_build::build::matches::<impl rustc_mir_build::build::Builder>::match_candidates ()
   from /home/anders/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-b6bcd19e02bce685.so
#2  0x00007ff0baef7fe4 in <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold ()
   from /home/anders/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-b6bcd19e02bce685.so
#3  0x00007ff0baea2f93 in rustc_mir_build::build::matches::<impl rustc_mir_build::build::Builder>::test_candidates::{{closure}} ()
   from /home/anders/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-b6bcd19e02bce685.so
#4  0x00007ff0bae9b2f1 in rustc_mir_build::build::matches::test::<impl rustc_mir_build::build::Builder>::non_scalar_compare ()
   from /home/anders/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-b6bcd19e02bce685.so
#5  0x00007ff0baea1362 in rustc_mir_build::build::matches::<impl rustc_mir_build::build::Builder>::match_simplified_candidates ()
   from /home/anders/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-b6bcd19e02bce685.so
#6  0x00007ff0baea2fdc in rustc_mir_build::build::matches::<impl rustc_mir_build::build::Builder>::test_candidates::{{closure}} ()
   from /home/anders/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-b6bcd19e02bce685.so
#7  0x00007ff0bae9b2f1 in rustc_mir_build::build::matches::test::<impl rustc_mir_build::build::Builder>::non_scalar_compare ()
   from /home/anders/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-b6bcd19e02bce685.so
#8  0x00007ff0baea1362 in rustc_mir_build::build::matches::<impl rustc_mir_build::build::Builder>::match_simplified_candidates ()
   from /home/anders/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-b6bcd19e02bce685.so
#9  0x00007ff0baea2fdc in rustc_mir_build::build::matches::<impl rustc_mir_build::build::Builder>::test_candidates::{{closure}} ()
   from /home/anders/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-b6bcd19e02bce685.so
#10 0x00007ff0bae9b2f1 in rustc_mir_build::build::matches::test::<impl rustc_mir_build::build::Builder>::non_scalar_compare ()
   from /home/anders/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-b6bcd19e02bce685.so
#11 0x00007ff0baea1362 in rustc_mir_build::build::matches::<impl rustc_mir_build::build::Builder>::match_simplified_candidates ()
   from /home/anders/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-b6bcd19e02bce685.so

If I reduce the number of enum variants to 5000, or stop using serde to derive Serialize/Deserialize, it starts working again.

Since it works using stable, but not using nightly, I thought it might be some kind of regression. I totally realize this may not be a bug and that what I'm doing (Serde + giant enum) is just not a good idea. Accept my apologies if this kind of thing shouldn't be reported here!

Metadata

Metadata

Assignees

Labels

A-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)A-proc-macrosArea: Procedural macrosC-bugCategory: This is a bug.I-crashIssue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.P-mediumMedium priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions