Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upSpurious failure in incremental\cache_file_headers.rs on Windows #38620
Comments
alexcrichton
added
the
A-spurious
label
Dec 26, 2016
This comment has been minimized.
This comment has been minimized.
alexcrichton
referenced this issue
Dec 26, 2016
Merged
rustdoc: Fix invalid HTML in stability notices #38329
This comment has been minimized.
This comment has been minimized.
|
This test relies on an environment variable being set correctly by |
alexcrichton
referenced this issue
Dec 27, 2016
Merged
clear discriminant drop flag at the bottom of a drop ladder #38600
This comment has been minimized.
This comment has been minimized.
|
Hm I think that may be a red herring. Presumably the env var is being set correctly because the compiler is recompiling, right? Digging more into this this morning I came across https://bugzilla.mozilla.org/show_bug.cgi?id=509960, a similar error, but no resolution there. One possibility is disk space running out but this is such a deterministic error that seems unlikely. |
alexcrichton
added
the
O-windows
label
Dec 27, 2016
This comment has been minimized.
This comment has been minimized.
|
My guess is that this is failing because something else has the file open. On Windows at least if there's an open file handle you're unable to delete that file. This is happening on both MSVC and GNU so I don't think it's linker specific (e.g. no problems like with mspdbsrv.exe I believe). @michaelwoerister you wouldn't happen to have any ideas about when we'd open this file, would you? IIRC the compiler never actually opens the output file, it just relies on the linker to do so. I also couldn't find anything in the compiletest incremental pieces as well... |
alexcrichton
referenced this issue
Dec 28, 2016
Merged
std: Clamp max read/write sizes on Unix #38622
This comment has been minimized.
This comment has been minimized.
|
Why would this only show up on AppVeyor? Is the Windows job object set up differently in rustbuild than in rust-buildbot? |
This comment has been minimized.
This comment has been minimized.
|
That's a good question! (I'm not sure why it's only on AppVeyor). We aren't actually using job objects on AppVeyor like we were on rust-buildbot, notably we aren't using rustjob. The rustbuild job object (which we do use), however, should be the same across rust-buildbot/AppVeyor. Between AppVeyor and rust-buildbot we've had a ton of changes, though. AppVeyor has likely a newer install of Windows and also a newer version of Visual Studio. |
This comment has been minimized.
This comment has been minimized.
|
It doesn't look like compiletest is doing anything itself that would hold the exe open. |
This was referenced Dec 29, 2016
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Dec 30, 2016
alexcrichton
referenced this issue
Dec 30, 2016
Merged
appveyor: Attempt to debug flaky test runs #38695
bors
added a commit
that referenced
this issue
Dec 30, 2016
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Dec 30, 2016
This comment has been minimized.
This comment has been minimized.
|
I can't think of anything special that this test case. It will try to overwrite the executable for each revision, but all the other incremental test cases do that too. |
This was referenced Feb 10, 2017
This comment has been minimized.
This comment has been minimized.
|
This hasn't showed up in ~2 months, so presumed fix by... something! |
alexcrichton commentedDec 26, 2016
•
edited
I've seen this failure a number of times on AppVeyor at this point:
where the actual error is:
So far I've been unable to isolate what's happening here much less reproduce it, unfortunately
Other examples are:
Conclusions so far is that:
cache_file_headers.rstest