You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of my recent changes has broken the step-over behaviour after first hitting a hard coded breakpoint immediately before a return (explicit or at the end of a method), where the calling frames next instruction is also a return. Repro is:
self halt Ctrl+E (evaluate it)
Press Debug button in walkback that results
F10 to step to next statement in the debugger that opens
Expected behaviour is to break again on the next statement. Actual behaviour is that the process just continues.
The workaround is to Step-into instead (F11). This has exactly the same behaviour on encountering a hard-code breakpoint anyway.
The step-over behaviour relies on the method with the halt being recompiled into debug, and the current stack frame and its calling frame (and the home frame of a block frame, if any) being rewritten to be at the same point in the debug code, and then the debugger just continues and the VM stops on encountering the next "break" instruction. The issue here is that the debugger leaves both the debug frames it creates positioned on the return statements. This is correct for the top frame (since F10 should execute the return), but not for the calling frame, which should be positioned on the break instruction inserted immediately before its return.
The text was updated successfully, but these errors were encountered:
One of my recent changes has broken the step-over behaviour after first hitting a hard coded breakpoint immediately before a return (explicit or at the end of a method), where the calling frames next instruction is also a return. Repro is:
self halt
Ctrl+E (evaluate it)Expected behaviour is to break again on the next statement. Actual behaviour is that the process just continues.
The workaround is to Step-into instead (F11). This has exactly the same behaviour on encountering a hard-code breakpoint anyway.
The step-over behaviour relies on the method with the halt being recompiled into debug, and the current stack frame and its calling frame (and the home frame of a block frame, if any) being rewritten to be at the same point in the debug code, and then the debugger just continues and the VM stops on encountering the next "break" instruction. The issue here is that the debugger leaves both the debug frames it creates positioned on the return statements. This is correct for the top frame (since F10 should execute the return), but not for the calling frame, which should be positioned on the break instruction inserted immediately before its return.
The text was updated successfully, but these errors were encountered: