Fix BigInteger outerloop test

[Rob-Hague]

This has presumably been failing since capping BigInteger to a maximum length

fixes #111814

[tannergooding]

/azp run runtime-libraries-coreclr outerloop-linux

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[tannergooding]

/azp run runtime-libraries-coreclr outerloop-linux

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[tannergooding]

/azp run runtime-libraries-coreclr outerloop-linux

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Rob-Hague]

😕

[tannergooding]

/azp run runtime-libraries-coreclr outerloop-windows

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[tannergooding]

Seems to be specific to the Linux containers. Let me ask a bit internally on this.

[ericstj]

Could just be they have a less memory, or a combination of less memory + concurrency. Could also be this test contributing

runtime/src/libraries/System.Runtime.Numerics/tests/BigInteger/BigIntegerToStringTests.cs

Lines 525 to 527 in 1b71136

	[OuterLoop("Takes a long time, allocates a lot of memory")]
	[SkipOnMono("Frequently throws OOM on Mono")]
	public static void ToString_ValidLargeFormat()

Here's all the Outerloop tests to consider https://github.com/search?q=repo%3Adotnet%2Fruntime%20path%3Asrc%2Flibraries%2FSystem.Runtime.Numerics%2Ftests%20Outerloop&type=code

[tannergooding]

Could also be this test contributing

Ah, good point. I didn't think about other outerloop tests in the same project.

That test in particular should probably use TryFormat instead, in which case we should get false because the buffer was too small in contrast to FormatException which indicates the format is bad (too large). That would also allow it to run in the innerloop, as it would take nanoseconds instead.

The other outerloop don't look to be doing anything "significant" memory wise, just doing extended validation that isn't required to run every PR.

[tannergooding]

@Rob-Hague is that something you'd be willing to try and fix as part of this PR? If not, I can push a commit up and try to finish getting CI passing for what's left

The change you have provided already is much appreciated and looks like it should help the original issue.

[Rob-Hague]

Took a quick look, even when using TryFormat(Span<char>.Empty, ... ) we still end up down this path with nMaxDigits ~= 1e9 for the exponential format:

runtime/src/libraries/Common/src/System/Number.Formatting.Common.cs

Lines 924 to 927 in 3688b59

	while (--nMaxDigits > 0)
	{
	vlb.Append(TChar.CastFrom((*dig != 0) ? (char)(*dig++) : '0'));
	}

The 'G' format has an early out so does not suffer the same problem. I have just commented the exponential tests since I have not determined whether an early out would always be valid.

I am signing off for the day, feel free to change or revert things in this branch

[tannergooding]

/azp run runtime-libraries-coreclr outerloop-linux

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[tannergooding]

Tests are passing now. There's some other unrelated failures still, but those are independent of what's being fixed here.