Debugger can't step into a function in a given situation with Linq

[Mucksh]

Hi, i think I found a little bug, I hope this is the right place to report it. Happens for me both in VS Code and Visual Studio (2022) on Windows 10 using .net 6. .net 5, and .net Framework 4.8 has no problems with it.

Not sure if it's already reported or a strange thing that only happens to me.

Description

It seems to happen if you have a select statement that off an IEnumerable of any type except int, when it uses a method to change the type to an int and you place a Where startement with any check after that.
I played a little bit around and it seems only to happen with an int and didn't found other type combinations or situations where this happens.

The simplest way to reproduce would be something like that:

        static void Main(string[] args)
        {
            var list = new[] { "1", "4", "h", "l1", "7" };
            var parsedList = list.Select(item => DoSomething(item)).Where(item => item == 1).ToList();
        }
        public static int DoSomething<T>(T input)
        {
            return 1;
        }

Just place a breakpoint in DoSomething and run.

VS Goes into break mode: ("Your app has entered a break state, but no code is currently executing that is supported by the selected debug engine (e.g. only native runtime code is executing).") - stepping seems still to work, no other error is shown

VS Code : the callstack shows: "Error processing stackTrace request. Unknown Error 0x80131c49" - and seems to be completely stuck

Overstepping it is completely safe

Like I said, when changing the .net version to 5 or framework 4.8 the error won't occure

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

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

Issue Details

---

Hi, i think I found a little bug, I hope this is the right place to report it. Happens for me both in VS Code and Visual Studio (2022) on Windows 10 using .net 6. .net 5, and .net Framework 4.8 has no problems with it.

Not sure if it's already reported or a strange thing that only happens to me.

Description

It seems to happen if you have a select statement that off an IEnumerable of any type except int, when it uses a method to change the type to an int and you place a Where startement with any check after that.
I played a little bit around and it seems only to happen with an int and didn't found other type combinations or situations where this happens.

The simplest way to reproduce would be something like that:

        static void Main(string[] args)
        {
            var list = new[] { "1", "4", "h", "l1", "7" };
            var parsedList = list.Select(item => DoSomething(item)).Where(item => item == 1).ToList();
        }
        public static int DoSomething<T>(T input)
        {
            return 1;
        }

Just place a breakpoint in DoSomething and run.

VS Goes into break mode: ("Your app has entered a break state, but no code is currently executing that is supported by the selected debug engine (e.g. only native runtime code is executing).") - stepping seems still to work, no other error is shown

VS Code : the callstack shows: "Error processing stackTrace request. Unknown Error 0x80131c49" - and seems to be completely stuck

Overstepping it is completely safe

Like I said, when changing the .net version to 5 or framework 4.8 the error won't occure

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

[tommcdon]

@Mucksh Thanks for the bug report! As a workaround, please try setting COMPLUS_ReadyToRun=0 in project properties.
In the project's launchSettings.json:

{
  "profiles": {
    "ConsoleApp29": {
      "commandName": "Project",
      "environmentVariables": {
        "COMPLUS_ReadyToRun": "0"
      }
    }
  }
}

[jeremybparagon]

I'm running into this too. The workaround mentioned above doesn't seem to be making a difference for me.

Here is my minimal example:

var objects = new object[1];
var sum = objects.Select(f).Sum();
Console.WriteLine(sum);

double f(object o)
{
    // Put a breakpoint anywhere in this function (or any nested method you call from this function).
    // The debugger will hit it but not be able to show the breakpoint that it hit.

    // Add any code you like here.

    return 0;
}

One workaround that will likely get me by is to add a call to ToList() before the call to Where when I'm debugging and this gets me stuck.

One thing to note is that when a user runs into this, it's a bit of a challenge to figure out what the issue is in a large codebase. If I'm correct, breakpoints won't work for any nested code that gets called for the Select, and since you don't get a stack trace, you don't know where to look for the problem. This might be even more of a setback if you want to break on exceptions, since it can be harder to narrow down where the exception is happening to implement the workaround.

Some additional notes: I'm thinking the issue occurs when the selector takes an object as input and returns a value with a type from the built-in value types (verified for bool and double). The issue doesn't just occur for Where, but also for some other methods like Sum and Aggregate. The issue occurs even if the selector is a lambda expression.

[astride]

One workaround that works for me is letting your source object be a List rather than an array.

In OP's code example, changing

var list = new[] { "1", "4", "h", "l1", "7" };

to

var list = new List<string> { "1", "4", "h", "l1", "7" };

led to the breakpoint inside DoSomething() being hit when debugging (Visual Studio 22, Windows 11, targeting .NET 6).

[2mik]

In my case the issue occurs with a list.

List<MyClass> list;
list.ForEach(item => DoSomething(item));

If I cange the code as below, the debugger works well:

foreach (MyClass item in list)
{
  DoSomething(item);
}

VS 2022, version 17.8.7
.NET 8