Test failure: JIT/HardwareIntrinsics/General/Vector256/Vector256_ro/Vector256_ro.sh Timed Out #60154
Assignees
Labels
arch-arm64
arch-x64
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
blocking-clean-ci
Blocking PR or rolling runs of 'runtime' or 'runtime-extra-platforms'
disabled-test
The test is disabled in source code against the issue
GCStress
os-linux
Linux OS (any supported distro)
os-mac-os-x
macOS aka OSX
os-windows
Milestone
Comments
VincentBu
added
arch-arm64
os-linux
dotnet-issue-labeler
bot
added
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsRun: runtime-coreclr gcstress0x3-gcstress0xc 20211003.1 One of error message:
|
|
This looks to be a simple timeout issue under GCStress. The test likely needs to be split apart like we did for some of the other scenarios. @echesakov, you had some tool or infrastructure to help support splitting these IIRC? |
JulieLeeMSFT
removed
the
untriaged
@tannergooding Correct, I stashed it here. We should probably resurrect and improve that work. |
|
Failed again in: runtime-coreclr gcstress0x3-gcstress0xc 20211017.1 Failed test: One of error message: |
|
Failed again in: runtime-coreclr r2r-extra 20211024.1 Failed test: Error message: |
|
Failed again in: runtime-coreclr gcstress0x3-gcstress0xc 20211107.2 Failed test: Error message: |
|
Failed again in: runtime-coreclr gcstress-extra 20211114.1 Failed test: One of error message: |
|
Failed again in: runtime-coreclr gcstress0x3-gcstress0xc 20211124.1 Failed test: Error message: |
|
Failed again in: runtime-coreclr gcstress0x3-gcstress0xc 20211205.1 Failed test: Error message: |
|
Failed again in: runtime-coreclr gcstress-extra 20211212.1 Failed test: Error message: |
|
@tannergooding @echesakovMSFT We continue to see lots of timeouts in these tests for gcstress / gcstress-extra, mostly (although apparently not exclusively) on Linux arm32. Should we just disable them for Linux arm32? Or for GCStress (until and if they are broken up)? |
|
@BruceForstall I think we should disable them for some of the scenarios. I will look into this. |
|
Failde again in: runtime-coreclr gcstress0x3-gcstress0xc 20211226.1 Failed test: Error message: |
|
Failed again in: runtime-coreclr gcstress0x3-gcstress0xc 20220102.1 Failed test: Error message: |
Merged
|
Failed again in: runtime-coreclr jitstress-isas-x86 20220115.1 Failed test: Error message: |
|
Hitting these failures https://dev.azure.com/dnceng/public/_build/results?buildId=1566046&view=logs&jobId=9eaa4d7e-225e-55b8-2a77-e1ac7e76d448&j=9eaa4d7e-225e-55b8-2a77-e1ac7e76d448&t=f70528f6-0b93-5c49-dfc7-de8b842ee9d6 |
ghost
removed
the
in-pr
|
#64140 won't have fixed the GCStress timeout issue which was a different issue from what got piled on here at the end. |
Merged
|
We hit a timeout again on the rolling build. Good news is it's only for one testcase, Could we keep this issue about the timeout and file new issues for different failures, even if it happens to be the same testcase? @VincentBu I hope you don't mind; I went ahead and moved your last comment to a new issue: #64587 |
sbomer
changed the title
This is something that is simply due to the number of tests that exist due to the number of hardware intrinsics that exist. This should get resolved as part of the general test cleanup changes (that I believe @trylek is working on). We could potentially split this explicitly into two projects in the interim, but I think that's the best we could do for now. |
sbomer
added
the
blocking-clean-ci
|
This is starting to repro more consistently - it caused the last two rolling builds to fail and is showing up in lots of PR runs: https://runfo.azurewebsites.net/search/tests/?q=started%3A~7%20definition%3Aruntime%20name%3A%22jit%2Fhardwareintrinsics%2Fgeneral%2Fvector256%2Fvector256_ro%2Fvector256_ro.sh%22 Could we bump the priority on fixing this, or disable the testcase? |
|
Thanks @echesakovMSFT - so the failure is actually due to the intrinsics being unsupported on ARM? Do we know why they are timing out? It would be great if we could get at least Vector256_ro disabled tonight before the next rolling build, even if the others take longer to fix. edit: I opened #64653 to selectively disable that test. Let me know if you prefer to take that or #63357. |
|
My guess is that each intrinsic call throws |
sbomer
added
the
disabled-test
|
|
Merged
echesakov
added a commit
that referenced
this issue
Feb 3, 2022
Disable intrinsics tests that throw NotSupportedPlatformException on the corresponding platforms: * Add JIT/HardwareIntrinsics/** to ExcludeList on Arm32 in src/tests/issues.targets * Add JIT/HardwareIntrinsics/General/Vector256/** to ExcludeList on Arm64 in src/tests/issues.targets * Add JIT/HardwareIntrinsics/X86/** to ExcludeList on Arm64 in src/tests/issues.targets * Add JIT/HardwareIntrinsics/General/Vector64/** to ExcludeList on X64 in src/tests/issues.targets * Add JIT/HardwareIntrinsics/Arm/** to ExcludeList on X64 in src/tests/issues.targets * Add JIT/HardwareIntrinsics/General/Vector64/** to ExcludeList on X86 in src/tests/issues.targets * Add JIT/HardwareIntrinsics/Arm/** to ExcludeList on X86 in src/tests/issues.targets
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.
Run: runtime-coreclr gcstress0x3-gcstress0xc 20211003.1
Failed test;
One of error message:
The text was updated successfully, but these errors were encountered: