[GCStress] coreroot_determinism test #50704
Labels
Milestone
Comments
dotnet-issue-labeler
bot
added
the
untriaged
AaronRobinsonMSFT
added
the
disabled-test
|
Failed again in runtime-coreclr r2r-extra 20210404.1 Failed test: Error message: |
|
Please note that runtime-coreclr r2r-extra is a Crossgen1 test which seems to indicate that the problem is actually not Crossgen2-specific. |
@trylek Even with the above line? That is why I had originally tagged it crossgen2. |
|
Hmm, sorry, you're right, while the r2r-extra is generally a Crossgen1 test, this is one of the few tests that have Crossgen2 hardcoded in their project script. One traditional problem we had several times in the past was that the COMPlus variable settings for GC stress got inadvertently applied to the managed Crossgen2 compiler itself, that is naturally 1-2 orders of magnitude slower and prone to timing out. |
|
Perhaps these tests should be disabled when CrossGen2 is involved somehow? I guess these tests involve CrossGen2 so maybe they are not GCStress compatible. |
|
Well, I think that the R2R code Crossgen2 produces is generally GC stress-compatible, it's just that Crossgen2 itself is a too big managed test app to run under GC stress and successfully compile something in ten minutes or so. Having said that, you're right that the determinism test is not about any runtime stress at all, the purpose of the test is to validate that parallelized Crossgen2 produces deterministic results. And I think it's due to the special nature of the test that runs Crossgen2 twice that it bypasses the provisions I added to CLRTest.Crossgen.targets to suppress the GC stress runtime variables for the duration of Crossgen2 compilation. I'll mark the test as GC stress-incompatible. |
|
Hmmm. The test is actually marked as GCStressIncompatible. In such case I suspect it's most likely a test infra script issue - the YAML files have special provisions for dealing with GC stress tests and maybe in this particular case the fact that it's also a R2R test causes the stress flag not to propagate to the inner build script. I'll take a look what might be causing that. |
|
Failed again in runtime 20210418.3 Failed test: Error message: Historical failures of this test has updated in this comment |
|
Failed again in runtime-coreclr r2r-extra 20210529.1 Failed test: Error message: Historical failures of this test has updated in this comment. |
|
Failed again: runtime-coreclr gcstress-extra. Stack trace: |
|
Failed again in runtime-coreclr gcstress-extra 20210801.1 Failed test: Error message: |
|
I have a new theory why this is happening. As @janvorli explained to me the other day, one subtle difference between Windows shell and bash is that, in bash, setting an environment variable to an empty string doesn't actually clear it, you need to unset it. I believe we've got it wrong here: Interestingly enough someone fixed the last case (or perhaps added it later) without noticing the pre-existing bug. Due to this fact, on Linux, we still run Crossgen2 itself under GC stress mode, slowing it down to the point of timing out systematically. I'll put out a PR to fix this. Thanks Tomas /cc @dotnet/crossgen-contrib |
ghost
added
the
in-pr
|
yeah sorry I had added the GC and wanted to change the others too use |
ghost
removed
the
in-pr
|
I think |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Failing on most platforms architectures in different manners, but all are timeouts when GCStress is enabled.
Windows x86 Checked gcstress0xc
Windows x64 Checked gcstress0x3
OSX arm64 Checked gcstress0x3
The text was updated successfully, but these errors were encountered: