Span CopyTo Span - Crashes .Net

[abbotware]

There appears to be some sort of threading issue in the System.Memory 4.5.3 running on .Net Framework for the following code:

Memory<byte> memory = new byte[100];
ReadOnlySpan<byte> temp = new byte[30];
temp.CopyTo(memory.Span);

attached is a sample program that will crash the error:

The process was terminated due to an internal error in the .NET Runtime at IP 00007FFE09357BFD (00007FFE091A0000) with exit code 80131506.

category:correctness
theme:gc-info
skill-level:expert
cost:medium

[abbotware]

This program crashes on .Net Framework 4.72 and 4.8 using System.Memory" Version="4.5.3"
CPU has 8 cores

Program was written as a stress test so it does the bare minimum amount of code to reproduce the crash

Program.txt

[GrabYourPitchforks]

Confirmed on Win10 18363.418 w/ .NET Framework 4.8 x64. Crash is coming from the GC, which might imply that there's a ref byte somewhere in System.Memory.dll that isn't properly being GC tracked.

[abbotware]

GC sounds plausible - from my tests - If you reduce the number of new / allocations (ie move the allocation out of the loops)... it won't crash..

[eerhardt]

I caught a Managed Debugging Assistant with this code:

Managed Debugging Assistant 'FatalExecutionEngineError' 
  Message=Managed Debugging Assistant 'FatalExecutionEngineError' : 'The runtime has 
encountered a fatal error. The address of the error was at 0x1996a6d6, on thread 0xb2078. The error 
code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of 
user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, 
which may corrupt the stack.'

[jkotas]

https://github.com/dotnet/coreclr/issues/27924 is the root cause of this crash.

[abbotware]

@jkotas - if a root cause has been identified in the jitter .cpp code - I suspect this can't be fixed with a new System.Memory dll... will it require a patch to the framework ?

[jkotas]

It can be worked around in System.Memory by avoiding the code pattern that hits the JIT bug.

[abbotware]

any update on a fix for this issue?

[jkotas]

We are evaluating several options for addressing this. It is going to take several months to get the fix out for .NET Framework, current ETA May 2020.

[Anipik]

It seems like it was fixed for net core by #1059
@jkotas any update on fix for .NetFramework ?

[jkotas]

The fix for .NET Framework is tracked by https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1026837 in the internal bug database.

@JulieLeeMSFT Could you please look into what we want to do here?

cc @dotnet/jit-contrib @eerhardt @GrabYourPitchforks

[JulieLeeMSFT]

@briansull please port the .NET Core fix to Framework.

[GrabYourPitchforks]

Huh, not sure why that internal issue was assigned to me. I've given it to Brian.

[briansull]

@jkotas
Is there a repro that can be run on the desktop?

D:\Public\Bugs\Runtime_13818>csc /o /unsafe repro.cs
Microsoft (R) Visual C# Compiler version 3.6.0-4.20251.5 (910223b6)
Copyright (C) Microsoft Corporation. All rights reserved.

repro.cs(18,18): error CS0103: The name 'Unsafe' does not exist in the current context

[eerhardt]

repro.cs(18,18): error CS0103: The name 'Unsafe' does not exist in the current context

You need to add a reference to https://www.nuget.org/packages/System.Runtime.CompilerServices.Unsafe/

[briansull]

How do I add that reference?

[eerhardt]

1. Create an empty directory and a Repro.csproj with the following contents:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net48</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.Runtime.CompilerServices.Unsafe" Version="4.7.1" />
  </ItemGroup>
</Project>

2. Add the code from Bad GCInfo generated for Unsafe.ByteOffset #13818 to a repro.cs file next to the above .csproj file.
3. dotnet run -c Release from the directory with Repro.csproj and repro.cs files.

[briansull]

Thanks, I have a repro case and have tested the fix. It looks good

[briansull]

I have checked in the fix for this issue into the Desktop .Net runtime for 4.8 and 4.7

The fix is expected to ship in the latter part of September as part of that month’s non security release. (barring any unexpected issues)

[briansull]

1026837 | [4.8] Possible data corruption in .NET Framework when using Span-based APIs
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1026837

[CarolEidt]

Thanks @briansull!