Infinite recursion during resource lookup within System.Private.CoreLib

[ViktorHofer]

  Microsoft.XmlSerializer.Generator.Tests -> /Users/runner/runners/2.163.1/work/1/s/artifacts/bin/Microsoft.XmlSerializer.Generator.Tests/netcoreapp5.0-Release/Microsoft.XmlSerializer.Generator.Tests.dll
  Process terminated. Infinite recursion during resource lookup within System.Private.CoreLib.  This may be a bug in System.Private.CoreLib, or potentially in certain extensibility points such as assembly resolve events or CultureInfo names.  Resource name: Arg_PlatformNotSupported
     at System.Environment.FailFast(System.String)
     at System.SR.InternalGetResourceString(System.String)
     at System.SR.GetResourceString(System.String, System.String)
     at System.PlatformNotSupportedException..ctor()
     at System.Runtime.Intrinsics.X86.Sse2.UnpackLow(System.Runtime.Intrinsics.Vector128`1<UInt16>, System.Runtime.Intrinsics.Vector128`1<UInt16>)
     at System.SpanHelpers.IndexOf(Char ByRef, Char, Int32)
     at System.String.Ctor(Char*)
     at System.Globalization.CultureData.GetDefaultLocaleName(System.String ByRef)
     at System.Globalization.CultureInfo.GetUserDefaultCulture()
     at System.Globalization.CultureInfo.InitializeUserDefaultCulture()
     at System.Globalization.CultureInfo.InitializeUserDefaultUICulture()
     at System.Globalization.CultureInfo.get_UserDefaultUICulture()
     at System.Globalization.CultureInfo.get_CurrentUICulture()
     at System.Resources.ResourceManager.GetString(System.String, System.Globalization.CultureInfo)
     at System.SR.InternalGetResourceString(System.String)
     at System.SR.GetResourceString(System.String, System.String)
     at System.PlatformNotSupportedException..ctor()
     at System.Runtime.Intrinsics.X86.Sse2.UnpackLow(System.Runtime.Intrinsics.Vector128`1<UInt16>, System.Runtime.Intrinsics.Vector128`1<UInt16>)
     at System.SpanHelpers.IndexOf(Char ByRef, Char, Int32)
     at System.String.Ctor(Char*)
     at System.AppContext.Setup(Char**, Char**, Int32)
  /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmp6d2682fe7c484b819ccdae1e361cc082.exec.cmd: line 2:  1408 Abort trap: 6           "/Users/runner/runners/2.163.1/work/1/s/artifacts/bin/testhost/netcoreapp5.0-OSX-Release-x64/dotnet" --fx-version 5.0.0 /Users/runner/runners/2.163.1/work/1/s/artifacts/bin/Microsoft.XmlSerializer.Generator.Tests/netcoreapp5.0-Release/dotnet-Microsoft.XmlSerializer.Generator.dll /Users/runner/runners/2.163.1/work/1/s/artifacts/bin/Microsoft.XmlSerializer.Generator.Tests/netcoreapp5.0-Release/Microsoft.XmlSerializer.Generator.Tests.dll --force --quiet
/Users/runner/runners/2.163.1/work/1/s/src/libraries/Microsoft.XmlSerializer.Generator/tests/Microsoft.XmlSerializer.Generator.Tests.csproj(44,5): error MSB3073: The command "export DOTNET_MULTILEVEL_LOOKUP=0 & "/Users/runner/runners/2.163.1/work/1/s/artifacts/bin/testhost/netcoreapp5.0-OSX-Release-x64/dotnet" --fx-version 5.0.0 /Users/runner/runners/2.163.1/work/1/s/artifacts/bin/Microsoft.XmlSerializer.Generator.Tests/netcoreapp5.0-Release/dotnet-Microsoft.XmlSerializer.Generator.dll /Users/runner/runners/2.163.1/work/1/s/artifacts/bin/Microsoft.XmlSerializer.Generator.Tests/netcoreapp5.0-Release/Microsoft.XmlSerializer.Generator.Tests.dll --force --quiet" exited with code 134.
##[error]src/libraries/Microsoft.XmlSerializer.Generator/tests/Microsoft.XmlSerializer.Generator.Tests.csproj(44,5): error MSB3073: (NETCORE_ENGINEERING_TELEMETRY=Build) The command "export DOTNET_MULTILEVEL_LOOKUP=0 & "/Users/runner/runners/2.163.1/work/1/s/artifacts/bin/testhost/netcoreapp5.0-OSX-Release-x64/dotnet" --fx-version 5.0.0 /Users/runner/runners/2.163.1/work/1/s/artifacts/bin/Microsoft.XmlSerializer.Generator.Tests/netcoreapp5.0-Release/dotnet-Microsoft.XmlSerializer.Generator.dll /Users/runner/runners/2.163.1/work/1/s/artifacts/bin/Microsoft.XmlSerializer.Generator.Tests/netcoreapp5.0-Release/Microsoft.XmlSerializer.Generator.Tests.dll --force --quiet" exited with code 134.

Happened during the libraries test assemblies build in https://dev.azure.com/dnceng/public/_build/results?buildId=482660.

[ViktorHofer]

cc @jkotas @tarekgh

[tarekgh]

CC @tannergooding it looks

 at System.Runtime.Intrinsics.X86.Sse2.UnpackLow

keep throwing. This is not resource issue.

[tarekgh]

@GrabYourPitchforks does this can be related to any of the optimizations you were doing with string?

[tannergooding]

There shouldn't be infinite recursion here. The method is recursive to itself yes, but we should be handling this in both AOT and JIT scenarios and it should be specially compiled down to a punpckl* instruction (we should also not have any unguarded calls; that is, they should all go through an IsSupported check to help ensure the runtime can generate code for these methods).

Is there possibly some analysis a tool is doing/etc? I would've expected a StackOverflow exception rather than the above message (if we had a bug).

[jkotas]

My guess is that this is caused by using ARM or ARM64 CoreLib on x64.

[tannergooding]

Ah, I see, the Sse2 is throwing the PlatformNotSupportedException but the JIT is reporting true for IsSupported
The recursion is because looking up the resource string ends up going through the Span path again (and causing the same exception).

[tarekgh]

If this is the case, JIT should do better detection?

[tannergooding]

Better detection would require us to always treat intrinsics as recursive; regardless of whether S.P.Corelib was compiled for ARM/ARM64 or x86/x64
However, I think there are other issues you can run into under that scenario...

[jkotas]

Right, we will crash in number of different ways if the S.P.CoreLib.dll flavor does not match coreclr.dll/so flavor.

[benaadams]

From the method SpanHelpers.IndexOf(Char ByRef, Char, Int32) and the failure X86.Sse2.UnpackLow it would suggest its Vector128.Create that is failing.

However, all three of the Vector128.Create calls are behind either a Avx2.IsSupported check or a Sse2.IsSupported check and the Vector128.Create method itself takes different paths based on the supported checks (it should never fail, as it has an no intrinsic path).

[tannergooding]

Right. Its believed that the failure is due to a x86/x64 JIT and a ARM/ARM64 S.P.Corelib

[tannergooding]

@ViktorHofer, what are the next steps here? I'm not sure there is anything additional that can be done by the area-System.Runtime.Intrinsics owners.

[ViktorHofer]

This can be closed now as it indeed was a mismatch of configurations. Thanks everyone.