Skip to content

Default value of build_base leads to races when running tests concurrently #72

Closed
@RalfJung

Description

@RalfJung

In miri, we use compiletest in multiple #[test] functions, so they are executed in parallel. We see a lot of test failures like

error: compilation failed!

status: exit code: 101

command: target/release/miri tests/run-pass/aux_test.rs -L /tmp --target=x86_64-unknown-linux-gnu -Z dump-mir=all -Z mir-opt-level=3 -Z dump-mir-dir=/tmp/aux_test -L /tmp/aux_test.stage-id.mir-opt.libaux -C prefer-dynamic -o /tmp/aux_test.stage-id -Zmir-opt-level=0 -Zmir-emit-validate=1

stdout:

------------------------------------------

------------------------------------------

stderr:

------------------------------------------

error: linking with `cc` failed: exit code: 1

  |

  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/tmp/aux_test.0.o" "-o" "/tmp/aux_test.stage-id" "/tmp/aux_test.crate.allocator.o" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-L" "/tmp" "-L" "/tmp/aux_test.stage-id.mir-opt.libaux" "-L" "/home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-L" "/tmp/aux_test.stage-id.mir-opt.libaux" "-l" "dep" "-L" "/home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-l" "std-ab8512bb715ab82f" "-Wl,-Bstatic" "/home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-53095306c4bf2e4a.rlib" "-Wl,-Bdynamic" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "pthread" "-l" "gcc_s" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util"

  = note: /usr/bin/ld: cannot find /tmp/aux_test.0.o: No such file or directory

          /usr/bin/ld: cannot find /tmp/aux_test.crate.allocator.o: No such file or directory

          collect2: ld returned 1 exit status

From the behavior of the bug (it only occurs spuriously), this feels a lot like a race condition.
(It also shows that compiletest messes with /tmp really badly, rather than creating its own subdirectory, which I would have expected.)

We track this in miri as rust-lang/miri#305

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions