runtime
runtime copied to clipboard
dotnet
Test failure in System.Numerics.Tensors.Tests.SingleGenericTensorPrimitives.SpanDestinationFunctions_SpecialValues
Failed in runtime-coreclr libraries-jitstress2-jitstressregs
Stack Trace:
/_/src/libraries/System.Numerics.Tensors/tests/TensorPrimitives.Generic.cs(444,0): at System.Numerics.Tensors.Tests.GenericFloatingPointNumberTensorPrimitivesTests`1.SpanDestinationFunctions_SpecialValues(SpanDestinationDelegate tensorPrimitivesMethod, Func`2 expectedMethod, Nullable`1 tolerance)
at InvokeStub_GenericFloatingPointNumberTensorPrimitivesTests`1.SpanDestinationFunctions_SpecialValues(Object, Span`1)
at System.Reflection.MethodBaseInvoker.InvokeWithFewArgs(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
Finished: System.Numerics.Tensors.Net8.Tests
Known Issue Error Message
Fill the error message using step by step known issues guidance.
{
"ErrorMessage": "GenericFloatingPointNumberTensorPrimitivesTests`1.SpanDestinationFunctions_SpecialValues",
"ErrorPattern": "",
"BuildRetry": false,
"ExcludeConsoleLog": false
}
Known issue validation
Build: :mag_right: https://dev.azure.com/dnceng-public/public/_build/results?buildId=660140
Error message validated: [GenericFloatingPointNumberTensorPrimitivesTests1.SpanDestinationFunctions_SpecialValues`]
Result validation: :white_check_mark: Known issue matched with the provided build.
Validation performed at: 5/1/2024 3:48:58 AM UTC
Report
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 16 | 139 | 194 |
Tagging subscribers to this area: @dotnet/area-system-numerics See info in area-owners.md if you want to be subscribed.
![dotnet-policy-service[bot] avatar](https://avatars.githubusercontent.com/in/285228?v=4 "Published by a pub.dev verified publisher"){kind=small}
Tagging subscribers to this area: @dotnet/area-system-numerics-tensors See info in area-owners.md if you want to be subscribed.
Looks similar in runtime-coreclr libraries-jitstressregs
Stack Trace:
at InvokeStub_GenericFloatingPointNumberTensorPrimitivesTests`1.SpanDestinationFunctions_SpecialValues(Object, Span`1)
at System.Reflection.MethodBaseInvoker.InvokeWithFewArgs(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
Finished: System.Numerics.Tensors.Tests
I can take a look and see if I can find an initial root cause, but I expect this is likely a JIT issue and unrelated to the libraries side of things.
CC. @jeffhandley
It is now failing in Runtime pipeline as well. Please see the Known issue report above.
This seems to be still failing in https://github.com/dotnet/runtime/pull/101859 which included the fix made in #101800
e.g.
System.Numerics.Tensors.Tests.SingleGenericTensorPrimitives.SpanDestinationFunctions_SpecialValues(tensorPrimitivesMethod: SpanDestinationDelegate { Method = Void ReciprocalSqrtEstimate[Single](System.ReadOnlySpan`1[System.Single], System.Span`1[System.Single]), Target = null }, expectedMethod: Func`2 { Method = Single ReciprocalSqrtEstimate(Single), Target = null }, tolerance: 0.01171875) [FAIL]
Assert.All() Failure: 256 out of 256 items in the collection did not pass.
[0]: Item: 1
Error: Assert.All() Failure: 2 out of 24 items in the collection did not pass.
[12]: Item: -1.40129846E-45
Error: Assert.Equal() Failure: Values differ
Expected: -�
Actual: NaN
[14]: Item: -1.17549421E-38
Error: Assert.Equal() Failure: Values differ
Expected: -�
Actual: NaN
...
I'm not able to reproduce the failure locally, on a machine with or without AVX512.
My best guess is that in some edge case scenario the code is calling the fallback instead of allowing the intrinsic implementation to kick in.
Changing it to be mustExpand with no managed implementation should avoid any potential for that, so that's what I'll get a fix up to do.
Should we disable this test for now? it's been blocking clean CI for two weeks now (e.g. I've just hit it in https://github.com/dotnet/runtime/pull/102132)
The issue is fixed with https://github.com/dotnet/runtime/pull/102098 and so disabling shouldn't be needed, just final sign-off
If, for whatever reason, the test still shows as flaky somewhere after then I think we can disable it then