F_DUPFD_CLOEXEC doesn't work on macOS 11.3 (v0.7.12)

[nhynes]

v0.7.12 introduced the use of F_DUPFD_CLOEXEC in Selector::try_clone, but when run on macOS 11.3, gives an error of

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }', src/main.rs:5:64

The error is fixed in mio v0.8, but currently tokio (v1.6) cannot run with feature = ["net"], as the Waker depends on cloning the Selector.

[Thomasdezeeuw]

The use of F_DUPFD_CLOEXEC was recently introduced because it would leak file descriptors otherwise, see #1496, b367a05 and d1617b5.

The tests run fine on macOS 11.4. Can you run Mio's tests or provide the code you're running which hits this error.

[nhynes]

Thanks for the quick response. The minimized code I've tested is:

Cargo.toml:

[package]
name = "mio-mwe"
version = "0.1.0"
edition = "2018"

[dependencies]
mio = { version = "0.7.12", features = ["os-poll"] }

main.rs:

/// Taken from `tokio`. Setting this to some other number works, actually.
/// https://github.com/tokio-rs/tokio/blob/master/tokio/src/io/driver/mod.rs#L91
const TOKEN_WAKEUP: mio::Token = mio::Token(1 << 31);

fn main() {
    let poll = mio::Poll::new().unwrap();
    let waker = mio::Waker::new(poll.registry(), TOKEN_WAKEUP).unwrap();
}

The mio unit tests run perfectly.

[Thomasdezeeuw]

Yeah that reproduced it, I'm going to pull v0.7.12 until we figure this out.

[Thomasdezeeuw]

I don't quite understand why registry_behind_arc, which calls Registry::try_clone (

mio/tests/poll.rs

Line 179 in c52635c

let registry = Arc::new(poll.registry().try_clone().unwrap());

), succeeds but the Waker::new call to try_clone fails...

[Thomasdezeeuw]

Some more notes.

Adding poll.registry().try_clone() (calling the problematic code) to the example above is fine.

Now, for some reason... the registry_behind_arc is also failing. I'm going to look into this more tomorrow.

[Thomasdezeeuw]

I think I found the issue after all. We don't provide a third argument to fcntl which means the argument is just whatever was in the register, which explain why it sometimes fails and sometimes succeeds.