ExcecutionEngineException when using StringBuilder on long strings

[delmyers]

Description

This issue was originally reported to Visual Studio (https://developercommunity.visualstudio.com/t/Prevent-using-precompiled-images-in-de/10363031) because it seems to only reproduce when turning off precompiled images under the debugger.

Reproduction Steps

1. Create a simple dotnet 7 console application with the following code:

var count = 100000;
_ = string.Join(" ", Enumerable.Range(0, count).Select(_ => "Hello world!"));

2. In Visual Studio, turn on the option in Tools > Options > Debugging > General > "Prevent using precompiled images..."

3. Start debugging.

Expected behavior

The application runs to completion.

Actual behavior

Either an ArgumentOutOfRangeException or an ExecutionEngineException is thrown.

Regression?

No response

Known Workarounds

No response

Configuration

Using dotnet 7.0.5, and the latest dotnet 8 preview.
Windows 11 x64

Other information

I think that it might be due to an overflow error while computing the length of the underlying span that is being used by the StringBuilder.

This repros in both dotnet 7, and dotnet 8 preview, though the location that the error is thrown from in dotnet 8 is different. I have heap dumps of the crashing processes in dotnet 7. I can make some for dotnet 8 if necessary as well.

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

This issue was originally reported to Visual Studio (https://developercommunity.visualstudio.com/t/Prevent-using-precompiled-images-in-de/10363031) because it seems to only reproduce when turning off precompiled images under the debugger.

Reproduction Steps

1. Create a simple dotnet 7 console application with the following code:

var count = 100000;
_ = string.Join(" ", Enumerable.Range(0, count).Select(_ => "Hello world!"));

2. In Visual Studio, turn on the option in Tools > Options > Debugging > General > "Prevent using precompiled images..."

3. Start debugging.

Expected behavior

The application runs to completion.

Actual behavior

Either an ArgumentOutOfRangeException or an ExecutionEngineException is thrown.

Regression?

No response

Known Workarounds

No response

Configuration

Using dotnet 7.0.5, and the latest dotnet 8 preview.
Windows 11 x64

Other information

I think that it might be due to an overflow error while computing the length of the underlying span that is being used by the StringBuilder.

This repros in both dotnet 7, and dotnet 8 preview, though the location that the error is thrown from in dotnet 8 is different. I have heap dumps of the crashing processes in dotnet 7. I can make some for dotnet 8 if necessary as well.

Author:	delmyers
Assignees:	-
Labels:	area-Diagnostics-coreclr, untriaged
Milestone:	-

[rwasef1830]

I am the original reporter of this bug. If any info is needed let me know.

[stephentoub]

It looks like this is hitting some kind of corruption. Just looking at this running on a recent .NET 8 build, we get to a point where the ValueStringBuilder's buffer is ~128K and we need to grow, so we call Grow(s.Length), and Grow ends up getting called with an impossible value, e.g. -615112336 (the real value should be 12).

[rwasef1830]

Here's a little tidbit that might help @stephentoub adding ToList on the enumerable call masks / solves the issue.

[tommcdon]

I am suspecting that this is a JIT/codegen issue as the issue only reproduces if Suppress JIT Optimization on module load (Managed only) under Debug->Options in VS is checkboxed. Adding @BruceForstall from the codegen team for thoughts.

[jkotas]

The crash seems to be caused by corrupted stack or invalid unwind info generated by the JIT.

Running the repro with checked runtime fails with assert in the JIT:

Assert failure(PID 47796 [0x0000bab4], Thread: 47852 [0xbaec]): Assertion failed 'compCanHavePatchpoints()' in 'System.String:Replace(System.String,System.String):System.String:this' during 'Importation' (IL size 353; hash 0xee849cf8; Tier0)

To run it with checked runtime, I have done self-contained publish of the app, overwrote the runtime .dlls with my local checked build and used start devenv /debugexe <path to .exe> to launch the debug session.

The crash does not repro with tiered compilation disabled.

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

This issue was originally reported to Visual Studio (https://developercommunity.visualstudio.com/t/Prevent-using-precompiled-images-in-de/10363031) because it seems to only reproduce when turning off precompiled images under the debugger.

Reproduction Steps

1. Create a simple dotnet 7 console application with the following code:

var count = 100000;
_ = string.Join(" ", Enumerable.Range(0, count).Select(_ => "Hello world!"));

2. In Visual Studio, turn on the option in Tools > Options > Debugging > General > "Prevent using precompiled images..."

3. Start debugging.

Expected behavior

The application runs to completion.

Actual behavior

Either an ArgumentOutOfRangeException or an ExecutionEngineException is thrown.

Regression?

No response

Known Workarounds

No response

Configuration

Using dotnet 7.0.5, and the latest dotnet 8 preview.
Windows 11 x64

Other information

I think that it might be due to an overflow error while computing the length of the underlying span that is being used by the StringBuilder.

This repros in both dotnet 7, and dotnet 8 preview, though the location that the error is thrown from in dotnet 8 is different. I have heap dumps of the crashing processes in dotnet 7. I can make some for dotnet 8 if necessary as well.

Author:	delmyers
Assignees:	-
Labels:	area-CodeGen-coreclr, area-Diagnostics-coreclr
Milestone:	8.0.0

[AndyAyersMS]

This reminds me of a bug @hoyosjs was asking me about internally, which I could never repro myself.

In that case the VM appeared to be passing two conflicting flags to the JIT : CORJIT_FLAG_TIER0 and CORJIT_FLAG_DEBUG_CODE. This confuses the JIT. because in one place it doesn't think patchpoints are possible, and in another it thinks they are possible.

Because of this, in release the JIT decides to put patchpoints into a method wth a localloc, which is not a supported scenario.