cargo panics when stdin to it is closed

[soenkehahn]

Problem

When execing e.g. cargo build with a closed stdin file descriptor, it panics with:

thread '<unnamed>' panicked at 'failed to acquire jobserver token: early EOF on jobserver pipe', src/librustc_codegen_ssa/back/write.rs:1348:29

Expected behavior: cargo should treat this the same as if stdin was a valid file descriptor that nothing gets written to.

Steps

This can be reproduced e.g. by a rust program that:

1. calls libc::close(libc::STDIN_FILENO),
2. calls nix::unistd::execvp to run cargo build on a project.

Here's an example repo including a reproduce.sh script to show the bug: https://github.com/soenkehahn/entr-cargo-bug

Possible Solution(s)

I think cargo could check with fcntl(libc::STDIN_FILENO, libc::F_GETFD) whether stdin is still open.

Notes

This is motivated by trying to use cargo in conjunction with entr. Since this commit it closes the stdin of the called command when using the -r (restart) option.

Output of cargo version:

cargo 1.33.0 (f099fe94b 2019-02-12)

On linux.

[joshtriplett]

Interesting! I suspect I might know what happened here, and if I'm correct, it isn't exactly cargo's or rustc's fault.

With stdin closed, the next file opened will become file descriptor 0.

So, when rustc or cargo creates a jobserver pipe, one end of it ends up as file descriptor 0.

Then, something else in the build process ends up either closing or reading from stdin, which confuses the jobserver.

It is not, in general, safe to run an arbitrary program with stdin closed. It's much safer to make stdin come from /dev/null.

[kevincox]

This seems related to rust-lang/rust#46981

[sanmai-NL]

@ehuss is this solved since rust-lang/rust#46981?

[ehuss]

I'm not sure. The particular reproduction given above started working in Rust 1.42. I'm not sure which change in that release altered the behavior (it was probably rust-lang/rust#68012). I'm going to close since this seems effectively resolved.