Skip to content

Stack overflow compiling serde_codegen 0.8 on OSX nightly #486

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

Closed
alexcrichton opened this issue Aug 9, 2016 · 8 comments
Closed

Stack overflow compiling serde_codegen 0.8 on OSX nightly #486

alexcrichton opened this issue Aug 9, 2016 · 8 comments
Assignees
Labels

Comments

@alexcrichton
Copy link
Contributor

I've been seeing some failures in compiling serde_codegen on Travis OSX builders using the nightly compiler:

   Compiling serde_codegen v0.8.0

error: failed to run custom build command for `serde_codegen v0.8.0`

process didn't exit successfully: `/Users/travis/build/alexcrichton/backtrace-rs/target/debug/build/serde_codegen-bb1ef080fae9a50a/build-script-build` (signal: 6, SIGABRT: process abort signal)

--- stderr

thread 'main' has overflowed its stack

fatal runtime error: stack overflow

I wonder, is the build script for serde-codegen doing anything that might cause this? This started regressing for me about the time MIR codegen landed, and there's a few known stack-space issues with MIR, but for now could an explicitly large stack be used perhaps?

@alexbool
Copy link

alexbool commented Aug 9, 2016

Hmm, I am using serde 0.8 with nightly and MIR on OS X for a while and have never run into this.

@oli-obk
Copy link
Member

oli-obk commented Aug 9, 2016

@alexcrichton the serde-codegen build script parses the entire crate with quasi and then expands the quasi macros. Increasing the stack size would be easy (pack everything in a thread and set the RUST_MIN_STACK env var), but I have no way of testing it. I could simply pack everything in a thread and you can experiment with the RUST_MIN_STACK env var yourself. Once that works, I can add code that sets the RUST_MIN_STACK var to a value you have found to work (as long as it isn't already set).

@alexbool I'm not sure whether Rust chooses the main thread's stack size depending on some system information, maybe it differs between your setup and @alexcrichton's.

The difference might also be because of some compiler options. debug mode + no optimizations will obviously use more stack space than release mode + optimizations.

@alexcrichton
Copy link
Contributor Author

Yeah unfortunately I've been unable to reproduce locally as well, it's only reproducing on Travis. It may be the case that rust-lang/rust#35409 fixes this, but in the meantime using RUST_MIN_STACK works for me!

@oli-obk
Copy link
Member

oli-obk commented Aug 9, 2016

Wait... It works without the changes or it should work with them?

@alexcrichton
Copy link
Contributor Author

Oh it doesn't work yet, I was gonna wait for a merge so I can test out

@oli-obk
Copy link
Member

oli-obk commented Aug 11, 2016

oh, good, that would have been weird.

I published 0.8.1 which does all the syntex stuff in a thread, so hopefully RUST_MIN_STACK works.

@alexcrichton
Copy link
Contributor Author

Worked for me, thanks!

@oli-obk
Copy link
Member

oli-obk commented Aug 12, 2016

Great

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

No branches or pull requests

4 participants