Opened on behalf of @danmosemsft
The test System.MemoryTests.MemoryTests/OwnedMemoryPinLargeArray has failed.
System.OutOfMemoryException : Array dimensions exceeded supported range.
Stack Trace:
at System.MemoryTests.MemoryTests.OwnedMemoryPinLargeArray()
Build : Master - 20180314.02 (Full Framework Tests)
Failing configurations:
cc @GrabYourPitchforks
This test was recently added in https://github.com/dotnet/corefx/pull/28032.
Would using https://github.com/dotnet/corefx/blob/master/src/System.Memory/tests/AllocationHelper.cs help in this case (even though it is used for native memory allocation)?
Or maybe we can use byte, instead of int.
Note it only failed on full framework.
Can we detect at runtime if large array support is enabled? We can skip the test if this flag is not enabled.
You could explicitly disable it on full framework, similar to our ToString tests:
https://github.com/dotnet/corefx/blob/a9e68bf3f993a853343fdc1b2c3bb9f7cfd5c411/src/System.Memory/tests/ReadOnlySpan/ToString.cs#L93
[SkipOnTargetFramework(TargetFrameworkMonikers.NetFramework, "Large array support is disabled.")]
I'd rather not use the target moniker because it _is_ a legitimate test if the proper switch has been enabled. But if we can't detect that switch at runtime then suppressing the test on full framework would be a viable alternative.
You could try catch for OOME specifically. That would have some value
Looked through the unmanaged side of things and I don't see any place where we expose this switch via a public API. Going to use @ahsonkhan's suggestion of skipping the test on full framework. I'm nervous about swallowing OOMs because they could mask latent issues with the test or with the code under test.
skipping the test on full framework
Can you please run it locally for TargetGroup=netfx to make sure the test passes (at least once)?
Manually verified against full framework by setting environment variable COMPLUS_gcallowverylargeobjects=0 and running, observing failure, then setting to 1 and running, observing success.
Most helpful comment
Looked through the unmanaged side of things and I don't see any place where we expose this switch via a public API. Going to use @ahsonkhan's suggestion of skipping the test on full framework. I'm nervous about swallowing OOMs because they could mask latent issues with the test or with the code under test.