[vim/vim] Termdebug problem with fast actions in vim (but not in gdb) (Issue #9158)
Simon Sobisch
Steps to reproduce
- have a bigger program with some frames
- start it via Termdebug
- change to GDB window
- enter "step" as command and execute with Enter
- keep Enter pressed for multiple seconds, so the command is re-executed
- vim (source) window is updated, everything works smooth
- restart the debug session
- use "S" - which is mapped to the
Step()function which does ancall s:SendCommand('-exec-step') - keep "S" pressed, very fast one sees the error message
Cannot execute this command while the selected thread is running.
- keeping it pressed brings up nearly a full screen of those messages; if
nomodifiableis active one (alternatively) gets
E21: Cannot make changes, 'modifiable' is off.
Expected behaviour
- no mapped keys, in this case "S", should "slip through" to the editor
- executing the step command (same happens for next) via Termdebug should ideally be as fast as on the gdb side, in any case there should be no message about "Cannot execute the command" (if in question "eat" the command)
Operating system
CentOS 8
Version of Vim
8.2.2760
Logs and stack traces
No response
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
Bram Moolenaar
I guess that when you press enter, the next character is only read at the prompt, thus after the previous step finished.
When using ":Step" it doesn't wait for the prompt. So it sends -exec-step while the program is running.
Should ":Step" wait for the prompt?
Simon Sobisch
Should ":Step" wait for the prompt? I think "yes", same for -exec-next.
Bram Moolenaar
> `Should ":Step" wait for the prompt?` I think "yes", same for `-exec-next`.
OK, let me add SendCommandIfStopped() and use it for :Next and :Step.
We'll have to check that this works properly.
--
"When I die, I want a tombstone that says "GAME OVER" - Ton Richters
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Simon Sobisch
Just rechecking as I've seen the issue yesterday again when testing the startup and decoding changes, I think it would be especially useful for :Step - and when this got in I also have something to monkey-see-monkey-do test for :Next later.
In any case it think it would be reasonable to have Step and Next in a function so adjustments are more easy.
Bram Moolenaar
> Just rechecking as I've seen the issue yesterday again when testing
> useful for `:Step` - and when this got in I also have something to
> monkey-see-monkey-do test for `:Next` later.
>
> In any case it think it would be reasonable to have `Step` and `Next`
> in a function so adjustments are more easy.
It should have the s:SendCommandIfStopped() function, which drops a
command if the debugger is not stopped.
--
Did Adam and Eve have navels?
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Simon Sobisch
Cool, haven't switched to that so far and now see that it is in and used for step and next. Will recheck the result next week, likely tomorrow.
Related: Would you mind a PR that moves Step, Next, Finish to a separate function, even if it is just the current one-liner or would you consider that "pollution"? [I'm using some "stuff" not commonly useful (yet) and between other check the filetype in those functions]
Bram Moolenaar
> Cool, haven't switched to that so far and now see that it is in and
> tomorrow.
>
> Related: Would you mind a PR that moves `Step`, `Next`, `Finish` to a
> separate function, even if it is just the current one-liner or would
> you consider that "pollution"? [I'm using some "stuff" not commonly
> useful (yet) and between other check the filetype in those functions]
without a function. If it is more, or shares code with other commands,
it should be a function. A function is more lines in a script, and
needs a name, thus only use it when useful.
--
A year spent in artificial intelligence is enough to make one
believe in God.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Simon Sobisch
A function is more lines in a script, and needs a name, thus only use it when useful.
It would so far only be useful for my personal scenario ("hooking" into those functions), so I'll keep that part out of pull requests.
Simon Sobisch
It should have the s:SendCommandIfStopped() function, which drops a command if the debugger is not stopped.
Tested that version, in the worst case (just keeping S pressed with a mapping to Step for 3 seconds) I've got 3 drops in the debuglog and >30 errors that the inferior is running - the issue here is that the command is send, and the "running" message doesn't get in fast enough.
I've worked around that with an assumed "step/next/finish will run the inferior" option as seen in the PR (now I get many drops and no error and "keep S pressed in Vim" is now half as fast as "keep pressed in gdb" (it waits longer because of my change, but I consider the general speed fast enough, because in Vim you can still follow the code in the source window [if you know it well], in GDB you can't).
While this issue is solved now the only culprit of SendCommandIfStopped: if the user asks for "step" while the inferior is "just running in a sleep" (like when it waits for a user input in the terminal), the user previously got the error message that this command can't be executed, now that never occurs. Trying another approach using a new SendCommandWithWait function that sets a wait state and then resets that on "stopped" event did not worked out, because sometimes the stopped event seem to not get trough.
All in all I consider the new one better as the last one, so I'd go with #9239.
Simon Sobisch
Good wood be sending a warning message to the user - is there an option to only do this (in the "dropped" case) if the current echoMsg is not the same as the one to be sent?
Bram Moolenaar
I'll include your suggested fix, with some more changes.
I'm not sure that telling the user that a command was dropped would be useful. Let's first try without it.
Perhaps if the stopped state can't be detected reliable we need to do something.
Bram Moolenaar
Closed #9158.
Simon Sobisch
Perhaps if the stopped state can't be detected reliable we need to do something.
It can't with the current design of "everything asynchronous and anonymous".
The only way that may work is:
- removing message anonymity by adding tokens to the messages sent (which is in general the suggested and commonly documented way), at least optional [I have a 1/3 finished solution for that locally, could start a draft PR if wanted]
- sent out an instruction that will tell us if the inferior is running or not
- internally block all further messages that potentially tinker with the run state (easiest: all messages, possibly also block interaction with the GDB buffer)
- that way wait for the answer to the message we sent out (has its token on return so can be distinguished)
- handle the answer - we now now the current state
- unblock everything
- do something with the information "stopped yes/no"
If all is left out but:
- token addition
- sending out a message that will tell us running yes/no (not sure which one this would be)
- checking the token to get the answer to the specific check we did
Then the check would be at least "more reliable" but not much as we could have received an interrupted/running message from a command sent out in the meantime.