Spurious failure in incremental\cache_file_headers.rs on Windows #38620
Comments
alexcrichton
added
the
A-spurious
|
This test relies on an environment variable being set correctly by |
|
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. |
|
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... |
|
Why would this only show up on AppVeyor? Is the Windows job object set up differently in rustbuild than in rust-buildbot? |
|
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. |
|
It doesn't look like compiletest is doing anything itself that would hold the exe open. |
This commit is an attempt to debug rust-lang#38620 since we're unable to reproduce it locally. It follows the [advice] of those with AppVeyor to use the `handle.exe` tool to try to debug what processes have a handle to the file open. This won't be guaranteed to actually help us, but hopefully it'll diagnose something at some point? [advice]: http://help.appveyor.com/discussions/questions/2898
appveyor: Attempt to debug flaky test runs This commit is an attempt to debug #38620 since we're unable to reproduce it locally. It follows the [advice] of those with AppVeyor to use the `handle.exe` tool to try to debug what processes have a handle to the file open. This won't be guaranteed to actually help us, but hopefully it'll diagnose something at some point? [advice]: http://help.appveyor.com/discussions/questions/2898
appveyor: Attempt to debug flaky test runs This commit is an attempt to debug rust-lang#38620 since we're unable to reproduce it locally. It follows the [advice] of those with AppVeyor to use the `handle.exe` tool to try to debug what processes have a handle to the file open. This won't be guaranteed to actually help us, but hopefully it'll diagnose something at some point? [advice]: http://help.appveyor.com/discussions/questions/2898
|
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 hasn't showed up in ~2 months, so presumed fix by... something! |
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.rstestThe text was updated successfully, but these errors were encountered: