Debugger fails on async lambda function

[vsfeedback]

Using .net core 2.2 c# ver 7.3 debugger fails on async lambda function (returning task) passed as parameter to another function.

The code works as expected but debugging experience is broken. Only breakpoint present after first await keyword is honored. Sometimes debugger passes several times over calling function. This can be reproduced by a trivial sample application (see bellow).

using System;
using System.Threading.Tasks;

internal class Program
{
    private static async Task Main(string[] args)
    {
        // Call Method1
        await CallAsyncFunction(async () =>
        {
            // Place a break point on this row
            Console.WriteLine("A");
            // Place a break point on this row 
            await Task.Delay(100);
            // Place a break point on this row 
            Console.WriteLine("B");
            await Task.Delay(100);
            Console.WriteLine("C");
        });

        Console.ReadLine();
    }

    private static async Task CallAsyncFunction(Func<Task> func)
    {
        await func();
    }
}

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/489653/debugger-fails-on-async-lambda-function.html
VSTS ticketId: 820585
These are the original issue comments:

Visual Studio Feedback System on 3/14/2019, 11:12 PM (20 hours ago):

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

These are the original issue solutions:
(no solutions)

[jan-joska]

More info on this bug.

Debugger fails on a parameter passed to the following function.
The code itself works as expected, but debugger can`t hit breakpoints or goes over the
same line several times.

private static async Task CallAsyncFunction(Func<Task> func)
{
    await func();
}

fails when parameter func is a local function
fails when parameter func is lambda function
works when regular function defined in an object is passed

[jcouv]

I was not able to repro using VS 15.9, nor VS 16.0 Preview 4.3 and recent Core 3.0. Neither did Gregg from debugger team.

[jan-joska]

Hello,
thank you for your reply. I can invoke this problem on two separate machines using VS 15.9.5 later updated to VS 15.9.10. Using .NET Core 2.2 (I don`t know if testing it on v 3.0 is relevant) with C# language version 7.3 (to allow async main function).

I made sure Postsharp wasn`t activated in the project as it was my first guess that it could cause this behavior.

I attach the following files:
TestProgramSolution.zip - Sample program I use to cause the behavior

DebugSessionScreens.zip - Numbered screen captures made every press of F10 during debugging session. The problem starts at number 3.

VisualStudioInfo.txt - Info about my VS

TestProgramSolution.zip
DebugSessionScreens.zip
VisualStudioInfo.txt

Thank you
Jan Joska

[jcouv]

Thanks for the repro solution. I tried it with 15.9.8, 15.9.9p1 and 16.0p4, using Core 2.2. Overall, things worked as I expected.

The only problem I observed was that the execution would not stop on the opening braces { when launching the debugger with F11 (issue) in some versions of VS.

I tried three scenarios:

1. launching with F11, then stepping with F10 and F11 (shown below)
2. setting a single breakpoint on line A and launching with F5 (I messed up the recording for that one, so not captured below)
3. setting multiple breakpoints (on lines A, 100 and B) and hitting F5 a few times (shown below)

(recorded with ScreenToGif and ShowOff AutoHotkey script)

Looking at your screenshots, pictures 3 and 4 do seem incorrect. I expect to see the first two statements (A and 100) inside the lambda to get highlighted in yellow, but the highlight remains on fun();, and those two statements never get highlighted (highlight jumps straight to line B)

@tmat @gregg-miskelly Please advise.

[gregg-miskelly]

@jan-joska I see that you have some extensions installed (OzCode? Resharper?). Does this problem happen if you disable all your extensions?

@jcouv If I used the built version of TestAsyncDebug.dll that Jan provided I still cannot reproduce Jan's problem, so whatever is going on, it isn't a compiler issue.

[jan-joska]

Ok, thank you ALL for your effort.
I indeed use PostSharp and Resharper. I disabled and suspended both. The problem still occures.
I suspect that there may be something wrong only how editor displays the current debugger position.
I noticed that the yellow stripe wrongly stays in CallAsyncFunction while the correct debugger position is somewhat indicated by blue border around statements you would expect it to be at. Can be seen in attached screen shot. The situation resolves itself after first await is passed in the lambda method. Then yellow stripe is in expected position. The code works as expected.

As noone can reproduce this behaviour I don`t know if this is worth investigating any more.

Thanks
J.J.

      internal class Program
{
    private static async Task Main(string[] args)
    {
        System.Diagnostics.Debugger.Launch();
        // Call Method1
        await CallAsyncFunction(async () =>
        {
            Console.WriteLine("a");
            Console.WriteLine("b");
            Console.WriteLine("c");
            Console.WriteLine("d");
            Console.WriteLine("e");
            Console.WriteLine("f");
            await Task.Delay(100);
            Console.WriteLine("g");
            Console.WriteLine("h");
            Console.WriteLine("i");
            Console.WriteLine("j");
            await Task.Delay(100);
            Console.WriteLine("k");
        });

        Console.ReadLine();
    }

    private static async Task CallAsyncFunction(Func<Task> func)
    {
        await func();
    }
}

[gregg-miskelly]

@jan-joska If you open the call stack window, that will show you where you are stopped, and we can use that to understand if this is a problem with the editor being strangely very slow to redraw the yellow 'current statement' highlight vs. some other problem.

If you do that - do all those breakpoints actually hit? If not, which breakpoints are missed and what is the call stack of the previous+next stopping locations?

[angelru]

This keeps happening in visual studio 2022