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:
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 onUserBreakEvent. 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.TopFrameCheckmethod in theDriverproject and launch it. ThetopFrameNamediffers fromProgram.EvaluationWithUserBreakInsidefor 2.56 protocol version, but works correctly for 2.51 (you can changeConnection.MINOR_VERSIONto 2.51 to check that).Here is what happens on my windows environment:
