Unexpected ENOTTY in sys::test_termios::test_tcgetattr

[joekain]

I occasionally see this failure if I run cargo test over and over:

failures:

---- sys::test_termios::test_tcgetattr stdout ----
    thread 'sys::test_termios::test_tcgetattr' panicked at 'assertion failed: `(left == right)` (left: `Some(Sys(ENOTTY))`, right: `Some(Sys(EBADF))`)', test/sys/test_termios.rs:15



failures:
    sys::test_termios::test_tcgetattr

test result: FAILED. 22 passed; 1 failed; 0 ignored; 0 measured

thread '<main>' panicked at 'Some tests failed', /home/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libtest/lib.rs:255

[carllerche]

Is this related to #155?

[joekain]

I believe this is a separate issue. If I comment out test_wait from #155 this issue still reproduces.

[joekain]

@carllerche, actually looks like this is sort of related to #155 at least in that it does not reproduce if I set RUST_TEST_THREADS=1. I ran cargo test in a loop for 2 hours with over 11,000 runs before I stopped it. I never saw a failure. Without the environment variable it never ran anywhere near this long without an error.

I don't think this is the same wait problem from #155 - it's a different race against other tests. test_tcgetattr iterates over file descriptors 0..5. What are fds 3, 4 and 5? I believe these fds are being opened and closed by other tests. Here's an example of a possible race:

• Thread 1: runs some other test which opens fd 3 which is not a TTY
• Thread 2: runs test_tcgetattr
• Thread 2: calls tcgetattr on fd 3 which fails with ENOTTY
• Thread 1: closes fd 3
• Thread 2: calls isatty on fd 3 which fails with EBADF
• Thread 2: test_tcgetattr compares the error codes and the assert fails.

Anyway, setting RUST_TEST_THREADS=1 avoids these races.