Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debugger step over doesn't work immediately after opening on a hard-code breakpoint #281

Open
blairmcg opened this issue Dec 22, 2016 · 0 comments
Labels

Comments

@blairmcg
Copy link
Contributor

blairmcg commented Dec 22, 2016

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:

  1. self halt Ctrl+E (evaluate it)
  2. Press Debug button in walkback that results
  3. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant