miri: Miri builds fail nondeterministically

On https://github.com/google/zerocopy/pull/506, this job succeeded while this job failed. Both jobs are running the same code on the same commit, and ran within a few minutes of one another using a pinned version of the Rust toolchain (nightly-2023-10-15). Here’s the error output from the failing job:

Error output

Preparing a sysroot for Miri (target: aarch64-unknown-linux-gnu)... done
   Compiling libc v0.2.149
   Compiling cfg-if v1.0.0
   Compiling rustversion v1.0.14
   Compiling ppv-lite86 v0.2.17
   Compiling either v1.9.0
   Compiling itertools v0.11.0
   Compiling getrandom v0.2.10
   Compiling rand_core v0.6.4
   Compiling rand_chacha v0.3.1
   Compiling rand v0.8.5
   Compiling testutil v0.0.0 (/home/runner/work/zerocopy/zerocopy/testutil)
error[E0463]: can't find crate for `cargo_metadata`
 --> testutil/src/lib.rs:5:5
  |
5 | use cargo_metadata::MetadataCommand;
  |     ^^^^^^^^^^^^^^ can't find crate

error[E0463]: can't find crate for `rustc_version`
 --> testutil/src/lib.rs:6:5
  |
6 | use rustc_version::{Channel, Version};
  |     ^^^^^^^^^^^^^ can't find crate
  |
  = help: maybe you need to install the missing components with: `rustup component add rust-src rustc-dev llvm-tools-preview`

error[E0463]: can't find crate for `time`
  --> testutil/src/lib.rs:99:24
   |
99 |             let desc = time::macros::format_description!("nightly-[year]-[month]-[day]");
   |                        ^^^^ can't find crate

error: cannot determine resolution for the macro `time::macros::format_description`
  --> testutil/src/lib.rs:99:24
   |
99 |             let desc = time::macros::format_description!("nightly-[year]-[month]-[day]");
   |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: import resolution is stuck, try simplifying macro imports

error[E0463]: can't find crate for `rustc_version`
  --> testutil/src/lib.rs:70:[23](https://github.com/google/zerocopy/actions/runs/6537994945/job/17753051531#step:11:24)
   |
70 |         let current = rustc_version::version_meta()?;
   |                       ^^^^^^^^^^^^^ can't find crate
   |
   = help: maybe you need to install the missing components with: `rustup component add rust-src rustc-dev llvm-tools-preview`

error[E0463]: can't find crate for `time`
   --> testutil/src/lib.rs:100:[24](https://github.com/google/zerocopy/actions/runs/6537994945/job/17753051531#step:11:25)
    |
100 |             let date = time::Date::parse(&pinned_versions.nightly, &desc).map_err(|_| {
    |                        ^^^^ can't find crate

error[E0463]: can't find crate for `time`
   --> testutil/src/lib.rs:103:[35](https://github.com/google/zerocopy/actions/runs/6537994945/job/17753051531#step:11:36)
    |
103 |             let adjusted = date - time::Duration::DAY;
    |                                   ^^^^ can't find crate

For more information about this error, try `rustc --explain E0463`.
error: could not compile `testutil` (lib) due to 7 previous errors

About this issue

Original URL
State: open
Created 8 months ago
Comments: 23 (12 by maintainers)

Commits related to this issue

[ci] Work around Miri bug on aarch64 targets (#519) Works around https://github.com/rust-lang/miri/issues/3125 — committed to google/zerocopy by joshlf 8 months ago

Most upvoted comments

Also, I’ve re-run the job, passing -vvv to cargo miri. Here’s the result.

Sorry, but cargo miri only recognizes -v -v, not -vv 😂

RalfJung on Oct 17, 2023

Looking at that cache action, this here is suspicious:

Before being persisted, the cache is cleaned of:

Any build artifacts with an mtime older than one week.

Potentially this can lead to having the .rmeta file deleted while the .rlib stubs that cargo-miri creates to make cargo happy stick around. Though we only create the .rlib file when rustc is actually invoked so it should only be a few milliseconds younger than the .rmeta file…

But anyway, a cache action deleting individual files from the cache like that is definitely fragile and I would advice against it. We assume we are in control of our cache directory.

RalfJung on Oct 17, 2023