ILLinker corrupts exception handler ranges for method

[BrzVlad]

Steps to reproduce:

1. Install VS 16.8 Preview 3 and .net 5.0 rc1
2. Build https://github.com/modulardev2/ThreadException (Client wasm project)
3. Go to binaries folder, disassemble System.Net.Http.dll, look for method <GetStringAsyncCore>d__41 MoveNext (). The EH clause ranges for the method are correct
4. Publish the same project (folder publish). Go to binaries folder, disassemble System.Net.Http.dll, look for same method as before and notice the clause ranges have been corrupted.

As part for publishing, _RunILLink is ran. This goes over the assemblies from the sdk, which are correct, and outputs them in the obj\Release\net5.0\linked\ folder. At this moment the method is corrupted. The linker seems to run as follows : https://gist.github.com/BrzVlad/e0f358c9d096c5acef745a1c49aae8d1

While I haven't tried building the project from linux with dotnet command, the behavior should be the same.

[BrzVlad]

cc @marek-safar

Causes release blocking issue dotnet/runtime#42628

[eerhardt]

I have narrowed down a repro that produces the issue even outside of brower-wasm:

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

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <PublishTrimmed>true</PublishTrimmed>
    <TrimMode>link</TrimMode>
    <EventSourceSupport>false</EventSourceSupport>
  </PropertyGroup>

</Project>

using System;
using System.Threading.Tasks;
using System.Net.Http;

namespace LinkerEHBug
{
    class Program
    {
        static async Task Main(string[] args)
        {
            var http = new HttpClient();
            var value = await http.GetStringAsync("http://www.msn.com");
            Console.WriteLine(value);
        }
    }
}

dotnet.exe publish -c Release -r win-x64 the above application, and run it. I get:

❯ .\bin\Release\net5.0\win-x64\publish\LinkerEHBug.exe
Unhandled exception. System.InvalidProgramException: Common Language Runtime detected an invalid program.
   at System.Net.Http.HttpClient.GetStringAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine& stateMachine)
   at System.Net.Http.HttpClient.GetStringAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.GetStringAsync(Uri requestUri, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.GetStringAsync(Uri requestUri)
   at System.Net.Http.HttpClient.GetStringAsync(String requestUri)
   at LinkerEHBug.Program.Main(String[] args) in F:\DotNetTest\LinkerEHBug\Program.cs:line 12
   at LinkerEHBug.Program.<Main>(String[] args)

I found that removing <EventSourceSupport>false</EventSourceSupport> allows the program to work properly. This property is set automatically for Blazor WASM apps, which is why it was repro'ing in Blazor by default.

cc @vitek-karas @MichalStrehovsky

[marek-safar]

The bug will be most likely in the substitution implementation for exception blocks with filters. This does not look like a regression on linker side but more like a bug exposed by changes in libraries

[lewing]

cc @kg

[eerhardt]

This does not look like a regression on linker side but more like a bug exposed by changes in libraries

I think this change to HttpClient.GetStringAsyncCore in the libraries is exposing this linker bug - dotnet/runtime@6b1b038#diff-256c040533e94c4e518e0453c5a7d4a0R176

An extra try-catch-finally was added to that method:

With EventSourceSupport=false, it looks like that new finally may be empty since HttpTelemetry.Log.IsEnable() will return false.

[marek-safar]

Simple repro

using System;

class X
{
	public static void Main ()
	{
		Test ();
	}

	static bool P => true;

	static void Test ()
	{
		try {
			if (!P)
				M ();

			M ();
		} catch when (Log ()) {
		}
	}

	static bool Log ()
	{
		return false;
	}

	static void M ()
	{
	}
}