Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CI random failure on x86_64-apple-2 InvalidInput in create_dir_all while running test/rustdoc/primitive/no_std.rs #109397

Closed
ehuss opened this issue Mar 20, 2023 · 3 comments · Fixed by #109509
Labels
A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason) A-testsuite Area: The testsuite used to check the correctness of rustc O-macos Operating system: macOS T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@ehuss
Copy link
Contributor

ehuss commented Mar 20, 2023

CI has failed a few times with the following error on x86_64-apple-2:

---- [rustdoc] tests/rustdoc/primitive/no_std.rs stdout ----
thread '[rustdoc] tests/rustdoc/primitive/no_std.rs' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }', src/tools/compiletest/src/runtest.rs:130:43

or:

---- [rustdoc] src/test/rustdoc/primitive/primitive-generic-impl.rs stdout ----
thread '[rustdoc] src/test/rustdoc/primitive/primitive-generic-impl.rs' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }', src/tools/compiletest/src/runtest.rs:125:43
Some tests failed in compiletest suite=rustdoc mode=rustdoc host=x86_64-apple-darwin target=x86_64-apple-darwin

I don't have any immediate theories as to the cause. It is conspicuous that it almost always happens on the same test.

The particular line in question is a call to the standard create_dir_all:

create_dir_all(&cx.output_base_dir()).unwrap();

I don't see anything particularly unusual in the implementation: std::fs::create_dir_all. The impl does a fairly standard libc call to mkdir. The macOS man page doesn't mention EINVAL, and I'm not sure under what circumstances that could happen with mkdir.

@ehuss ehuss added A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason) O-macos Operating system: macOS labels Mar 20, 2023
@jyn514
Copy link
Member

jyn514 commented Mar 21, 2023

the test in question:

#![no_std]
#![deny(warnings)]
#![deny(rustdoc::broken_intra_doc_links)]
// @has no_std/fn.foo.html '//a/[@href="{{channel}}/core/primitive.u8.html"]' 'u8'
// @has no_std/fn.foo.html '//a/[@href="{{channel}}/core/primitive.u8.html"]' 'primitive link'
/// Link to [primitive link][u8]
pub fn foo() -> u8 {}
// Test that all primitives can be linked to.
/// [isize] [i8] [i16] [i32] [i64] [i128]
/// [usize] [u8] [u16] [u32] [u64] [u128]
/// [f32] [f64]
/// [char] [bool] [str] [slice] [array] [tuple] [unit]
/// [pointer] [reference] [fn] [never]
pub fn bar() {}

@jyn514 jyn514 added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. A-testsuite Area: The testsuite used to check the correctness of rustc labels Mar 21, 2023
@jyn514
Copy link
Member

jyn514 commented Mar 21, 2023

Hmm, it stands out to me that this is one of the only tests where there's a directory with the same name as another test (tests/rustdoc/primitive.rs). Maybe mkdir returns an error if the directory already exists, and there's some race condition because the tests are run in parallel?

@ehuss
Copy link
Contributor Author

ehuss commented Mar 23, 2023

I sort of figured out what is going on. The following is a reproduction:

fn main() {
    use std::fs::{create_dir_all, remove_dir_all};
    use std::thread::spawn;
    for _ in 0..10000 {
        let _ = remove_dir_all("rustdoc");
        let t1 = spawn(|| {
            create_dir_all("rustdoc/primitive").unwrap();
            let _ = remove_dir_all("rustdoc/primitive");
            create_dir_all("rustdoc/primitive").unwrap();
        });
        let t2 = spawn(|| {
            create_dir_all("rustdoc/primitive/no_std").unwrap();
            let _ = remove_dir_all("rustdoc/primitive/no_std");
            create_dir_all("rustdoc/primitive/no_std").unwrap();
        });
        t1.join().unwrap();
        t2.join().unwrap();
    }
}

Essentially two tests are trying to create and delete the same directory at the same time. For some reason, macOS returns EINVAL in that situation. I don't think this is necessarily a flaw in Rust's create_dir_all implementation, more in the realm of "don't do that" (or a bug in macOS itself).

I have opened #109509 to fix this for the tests.

@bors bors closed this as completed in 2981d77 Mar 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason) A-testsuite Area: The testsuite used to check the correctness of rustc O-macos Operating system: macOS T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants