2.56 version of protocol is unable to enumerate frames properly while active evaluation

Open eterekhin opened this issue 3 years ago • 1 comments

Hi!

I've discovered that the 2.56 version of the protocol (the newest version for now) has a degradation. When we start an evaluation from Immediate window we expect that Debugger.Break() will be processed correctly, but thread.GetFrames () is seemed to return the wrong frames when we are stopped on UserBreakEvent. It stopped working between 2.51 and 2.56 versions.

I was able to build a stable repro in my fork, tested on Windows. Just add a breakpoint to the end of Program.TopFrameCheck method in the Driver project and launch it. The topFrameName differs from Program.EvaluationWithUserBreakInside for 2.56 protocol version, but works correctly for 2.51 (you can change Connection.MINOR_VERSION to 2.51 to check that).

Here is what happens on my windows environment:

Mar 25 '22 08:03 eterekhin

@thaystg, Hi! Sorry for the direct mention, but it may be a mono runtime issue, could you please take a look?

Mar 25 '22 08:03 eterekhin