-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test failure JIT\\jit64\\opt\\cse\\hugeexpr1\\hugeexpr1.cmd #74555
Comments
cc @ivdiazsa, maybe this needs to be redisabled for x86. |
@AntonLapounov another crossgen2 failure but this time on x86 |
It has been intermittently failing for a long time: #61825. |
I have looked at the dump; this is an OutOfMemoryException.
|
@trylek do you know if this might be related to running multiple tests in parallel on helix machines? how would we harden this scenario ? |
For the non-merged tests (still a majority) parallelization is controlled by the xunit console but I have no idea whether we have any "official" knobs for controlling that, some time ago we discussed this with Andrew in context of GC tests that are sometimes also sensitive to concurrent execution. I'll take a closer look and I'll try to figure out how to introduce the support for tests that need exclusive access to the running machine. |
this is marked as blocking outerloop. Moved it to 8 for now to determine if we can reduce parallelization for certain tests. |
Failed again in: runtime-coreclr outerloop 20220918.1 Failed test:
Error message:
|
Failed again in: runtime-coreclr outerloop 20220927.3 Failed test:
Error message:
|
Failed again in: runtime-coreclr r2r 20221009.1 Failed test:
Error message:
|
I think we should disable this test for Windows x86 for the time being, and keep this issue open until we investigate how we can fix it. Thoughts @mangod9 @AntonLapounov @trylek? |
should be fine if this is x86 only. |
I can send out a PR for adding the issues.targets entry. For the above discussion regarding test parallelization on x86, I no longer think it is related. The machines are physically x64 and even if the generated XUnit wrapper is run as an x86 app (I'm not sure about that), it's a very short app that basically only runs separate processes for the individual test cases. These processes run in separate address spaces that shouldn't be constrained by 32-bit considerations. I'm guessing it's just that Crossgen2 gets too close to the 2 GB limit and there's possibly a bit of non-determinism due to internal parallelization that probably affects the exact amount of GC memory and causes the test to pass or fail with a certain probability. We can take a closer look what exact data is causing the problem ( |
As the test is disabled in issues.targets, we no longer need the "blocking outerloop" label. |
This is basically a 32-bit compilation limit, I don't think we can do anything reasonable about it in .NET 8 timeframe, moving to future as 64-bit platforms are sufficiently widespread so that this is basically a corner case that shouldn't affect most customers. |
Run: runtime-coreclr outerloop 20220824.6
Failed test:
Error message:
The text was updated successfully, but these errors were encountered: