.NET 8 Blazor - Memory Corruption

[TomElcome]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Ran into what looks like memory corruption in my blazor project. This only seems to happen in web assembly and in the release configuration in visual studio. It also doesn't seem to occur in .NET 7. Code used to cause this error is pictured below:

<span>Scroll down to item 1000 to view memory corruption</span>
@for (int j = 0; j < 2000; j++)
{
    <div>This works as expected: @(j < 1500 ? j.ToString() : "N/A")</div>
    <div>This becomes corrupted: @(j < 1500 ? j : "N/A")</div>
}

The top line in each iteration is showing the expected behaviour of the code. The bug occurs only when: rendering large quantities of data, using the ternary operator and when we are not explicitly converting 'j' to a string

Example of the error occuring:

Expected Behavior

All values would be rendered for each iteration of the for loop without showing corrupted text.

Steps To Reproduce

Create standard Blazor WebAssembly App. and change configuration to release. Next put erroneous block of code onto page.
Then build and run, scrolling down the page to encounter the memory corruption.

Exceptions (if any)

No response

.NET Version

8.0.0

Anything else?

Sample Project Repository: https://github.com/TomElcome/BlazorWasmMemoryCorruption
REPL: https://blazorrepl.telerik.com/myOTEtbf19p2whkm36

[mkArtakMSFT]

@lewing FYI

[dotnet-policy-service]

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

[steveisok]

@kg can you please investigate?

[kg]

Reduced repro:

<span>Scroll down to item 1000 to view memory corruption</span>
@for (int j = 0; j < 2000; j++)
{
    <div>@(j < 1500 ? "test" : "N/A")</div>
    <div>@(j < 1501 ? j : "N/A")</div>
}

Produces:

998
test
<garbage>
test
<garbage>
test
<garbage>

What appears to be happening is that the buffer blazor uses to send strings and other data to the DOM is either getting corrupted or it's being read from using the wrong type. Have to dig in deeper to figure out why.

[kg]

cc @BrzVlad this appears to be related to interpreter tiering; it breaks as soon as the loop (j++) iterates ~999 times, which aligns with interp tiering threshold of 1000. i think the loop is getting tiered and then RenderTreeBuilder.AddContent is passed the wrong thing somehow.

EDIT: I should note it seems like this may be fixed in 9.

[lewing]

@kg so you were able to reproduce in net8.0 but not net9.0?

[kg]

@kg so you were able to reproduce in net8.0 but not net9.0?

I haven't reproduced it locally, but Mackinnon tested it on both and couldn't repro in 9.