Standard file descriptor checks cause abort on startup with strict rlimit

[QuineDot]

Cause

PR 75295 added polls to the standard file descriptors on startup; if they are closed, it attempts to reopen them to /dev/null. If RLIMIT_NOFILE is too low, the polling (or opening) will cause an abort.

Reported by @edre on URLO; diagnosed by @cuviper.

The rlimit could be checked ahead of time.

Code

I tried this Docker configuration

FROM rust:1.48
RUN rustup target add x86_64-unknown-linux-musl
RUN echo 'fn main(){println!("hi");}' > hi.rs; rustc --target x86_64-unknown-linux-musl -o hi hi.rs
RUN python3 -c 'import resource,subprocess;print(subprocess.run(["/hi"],preexec_fn=lambda: resource.setrlimit(resource.RLIMIT_NOFILE, (0,0))))'

I expected to see this happen: Successful execution

Instead, this happened: Process aborted

Version it worked on

It most recently worked on: Rust 1.47

Versions with regression

Rust 1.48 and forward.

Related issues

• Rust's stdio should not ignore EBADF error on non-windows platforms #47271
• Closed standard file descriptors don't generate errors anymore on Unix #88825

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged

[the8472]

Are file descriptors 0-2 open at the time of the abort?

Edit, ah, I see this is a limitation of poll(2), not of the process being incorrectly spawned. This could be solved by a fallback to calling fstat on individual fds if poll doesn't work.

[the8472]

  EINVAL The  nfds  argument  is  greater than {OPEN_MAX}, or one of the fd members refers to a
         STREAM or multiplexer that is linked (directly or indirectly) downstream from a multi‐
         plexer.

   EINVAL The nfds value exceeds the RLIMIT_NOFILE value.

[m-ou-se]

We're happy to review a patch for this. (E.g. falling back to fstat if poll returns EINVAL.)