[Dexter] Use continue when resuming lldb execution to reach breakpoint #156481
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently, Dexter's interface for lldb and lldb-dap has a post-step hook that checks to see whether lldb reports that we stopped because we completed a step, and if so checks to see whether the current $pc address also matches a known breakpoint whose conditions (if any) are met, and if so it requests to "step in", so that we "resume" execution, stopping again at the current address, such that lldb now reports that we have hit a breakpoint and provides the list of breakpoints that were hit. This logic has a flaw however: the call to "step in" sets an implicit breakpoint on the next line. In Dexter's default stepping mode this is not an issue, as we intend to step there eventually. When we use DexContinue, however, we set a breakpoint from which we wish to continue to the next user-specified breakpoint, rather than stepping. Currently, there is a bug where Dexter sets a DexContinue breakpoint, arrives at that bp from a step, requests "step in" so that LLDB gives us the hit breakpoint ID, requests "continue" to hit the next user breakpoint, and then arrives at the next line after the continue due to the earlier "step in" request. This effectively negates the DexContinue command. This patch fixes this behaviour by using "continue" instead of "step in" in the post-step hook, ensuring that no implicit breakpoint is set so that we do not incorrectly stop at the next line.
OCHyams
approved these changes
Sep 2, 2025
|
Looking at the new output, Stephen's patch did fix the issue we were seeing at first. With that fixed, the bot has run into a new failure mode, which is much simpler. The "step index" numbers are different on that bot than on x86 / locally for some reason. Should be fixed in #156832 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, Dexter's interface for lldb and lldb-dap has a post-step hook that checks to see whether lldb reports that we stopped because we completed a step, and if so checks to see whether the current $pc address also matches a known breakpoint whose conditions (if any) are met, and if so it requests to "step in", so that we "resume" execution, stopping again at the current address, such that lldb now reports that we have hit a breakpoint and provides the list of breakpoints that were hit.
This logic has a flaw however: the call to "step in" sets an implicit breakpoint on the next line. In Dexter's default stepping mode this is not an issue, as we intend to step there eventually. When we use DexContinue, however, we set a breakpoint from which we wish to continue to the next user-specified breakpoint, rather than stepping. Currently, there is a bug where Dexter sets a DexContinue breakpoint, arrives at that bp from a step, requests "step in" so that LLDB gives us the hit breakpoint ID, requests "continue" to hit the next user breakpoint, and then arrives at the next line after the continue due to the earlier "step in" request. This effectively negates the DexContinue command.
This patch fixes this behaviour by using "continue" instead of "step in" in the post-step hook, ensuring that no implicit breakpoint is set so that we do not incorrectly stop at the next line.
Likely fixes the issue reported at: #152721 (comment)