error: Could not compile `curl-sys` due to stack overflow, OS X 10.9

[nickolay]

I'm getting an error while building curl-sys >= 0.4.9 (more specifically it seems to be introduced in #225):

thread 'main' has overflowed its stack
fatal runtime error: stack overflow
error: Could not compile `curl-sys`.

Caused by:
    process didn't exit successfully: `rustc --crate-name build_script_build curl-sys/build.rs --color always --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=9653e13476469367 -C extra-filename=-9653e13476469367 --out-dir /path/to/target/debug/build/curl-sys-9653e13476469367 -C incremental=/path/to/target/debug/incremental -L dependency=/path/to/target/debug/deps --extern cc=/path/to/target/debug/deps/libcc-7a54d0e3950ef197.rlib --extern pkg_config=/path/to/target/debug/deps/libpkg_config-efadd2cff0cc6740.rlib` (signal: 6, SIGABRT: process abort signal)

Happens both with rustc 1.31.0-nightly (cae6efc37 2018-10-27) and stable rustc 1.30.0 (da5f414c2 2018-10-24)

I took a shot in the dark and tried (after cargo clean):

RUST_MIN_STACK=1000000 cargo build

-- that worked.

This is on a very old OS X 10.9.5.

[alexcrichton]

Thanks for the report! Would you be able to get a stack trace out of rustc? My guess is that it's related to this very long list of method chains but even that shouldn't blow the stack in theory. Could you also try breaking that in half and seeing if it fixes the issue for you?

[nickolay]

You're right, reducing the number of chained calls by at least 24 stops the error (e.g.

curl-rust/curl-sys/build.rs

Lines 74 to 98 in ede3241

	.define("HAVE_ZLIB_H", None)
	.define("HAVE_LIBZ", None)
	.file("curl/lib/asyn-thread.c")
	.file("curl/lib/base64.c")
	.file("curl/lib/conncache.c")
	.file("curl/lib/connect.c")
	.file("curl/lib/content_encoding.c")
	.file("curl/lib/cookie.c")
	.file("curl/lib/curl_addrinfo.c")
	.file("curl/lib/curl_ctype.c")
	.file("curl/lib/curl_memrchr.c")
	.file("curl/lib/curl_range.c")
	.file("curl/lib/curl_threads.c")
	.file("curl/lib/dotdot.c")
	.file("curl/lib/easy.c")
	.file("curl/lib/escape.c")
	.file("curl/lib/file.c")
	.file("curl/lib/fileinfo.c")
	.file("curl/lib/formdata.c")
	.file("curl/lib/getenv.c")
	.file("curl/lib/getinfo.c")
	.file("curl/lib/hash.c")
	.file("curl/lib/hostasyn.c")
	.file("curl/lib/hostcheck.c")

), and the stack has what looks like 63 repeated instances of this:

frame #617: ...`rustc_mir::build::expr::as_place::_$LT$impl[ ... ] + 160
frame #618: ...`rustc_mir::build::expr::as_place::_$LT$impl[ ... ] + 1749
frame #619: ...`rustc_mir::build::expr::as_rvalue::_$LT$impl[ ... ] + 9770
frame #620: ...`rustc_mir::build::expr::into::_$LT$impl[ ... ] + 335
frame #621: ...`rustc_mir::build::expr::as_temp::_$LT$impl[ ... ] + 1040
frame #622: ...`rustc_mir::build::expr::as_operand::_$LT$impl[ ... ] + 135
frame #623: ...`rustc_mir::build::expr::as_operand::_$LT$impl[ ... ] + 553
frame #624: ...`rustc_mir::build::expr::as_operand::_$LT$impl[ ... ] + 157
frame #625: ...`_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$alloc..vec..SpecExtend$LT$T$C$$u20$I$GT$$GT$::from_iter::h09c45bbcce953471 + 375
frame #626: ...`rustc_mir::build::expr::into::_$LT$impl[ ... ] + 12405
frame #627: ...`rustc_mir::build::expr::as_temp::_$LT$impl[ ... ] + 1040
frame #628: ...`rustc_mir::build::expr::as_place::_$LT$impl[ ... ] + 160
frame #629: ...`rustc_mir::build::expr::as_place::_$LT$impl[ ... ] + 1749

(I've included two extra frames to show the overlap)

The complete output is at https://pastebin.com/s3ZVA2Ez

[alexcrichton]

Ok thanks for the stack trace! It looks like this may be rust-lang/rust#55471 upstream, but if you'd like to send a PR in the meantime to break the number of method calls please feel free!

[nickolay]

As I noted in https://github.com/alexcrichton/git2-rs/issues/180, I've since found out I could simply disable the default features of git2-rs, which removes the dependency on curl-rust, so I'll leave the honors to someone who has to build it.

Thanks for the super-quick answer and the pointer to the upstream issue!

[alexcrichton]

Ok! In that case I'm going to close this issue, and hopefully we'll resolve upstream issue soon too!