[vim/vim] Cannot check if your gdb works, continuing anyway (#8163)
Uri Moszkowicz
Describe the bug
I get this error running vim 8.2 when starting :Termdebug:
Error detected while processing function 2_StartDebug[2]..2_StartDebug_internal[50]..2_StartDebug_term:
line 97:
Cannot check if your gdb works, continuing anyway
Press ENTER or type command to continue
After a few seconds GDB starts anyway.
To Reproduce
Detailed steps to reproduce the behavior:
- Run vim
- Type :Termdebug
- Wait for error message
- A few seconds later, use GDB w/o problems
Expected behavior
I think my GDB takes a few seconds to start, since it loads over NFS. Looks like the script has a timeout waiting for it. I get this error message every time. Either we can increase the time limit, add the ability to disable the check, or log the error in some way that's not so visible.
Environment (please complete the following information):
- Vim version 8.2, GDB: 10
- OS: Redhat 7
- Terminal: GNOME Terminal
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Christian Brabandt
What limit works for you?
> Am 30.04.2021 um 20:14 schrieb Uri Moszkowicz ***@***.***>:
>
>
Uri Moszkowicz
How do I scroll up/down the program output window? This is what I get:
^[[A^[[A^[[A^[[A^[[A^[^[[A^[[A^[[A^[[A^[[A^[[A^[[B^[[B^[[B^B^B^B^[^[^[^[^[[A^[[A^[[A^[[B^[[B^[^[i^[^[^[^[^[^[[A^[[A^[[A^[[B^[[B^[[B^[^[^[^[^[^[^[^B^B^F^F^F
On Fri, Apr 30, 2021 at 1:41 PM Christian Brabandt ***@***.***>
wrote:
> Try increasing this limit here
> https://github.com/vim/vim/blob/4934ed34c3e2090d1963c89c629cd3ce81d3ecd1/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim#L275
>
> What limit works for you?
>
> > Am 30.04.2021 um 20:14 schrieb Uri Moszkowicz ***@***.***>:
> >
> >
> Reply to this email directly, view it on GitHub
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABNJJQWDS46BYONNTPCAQFLTLL2V5ANCNFSM435BRS3A>
> .
Daniel Nelson
I have a similar problem, after running the Termdebug command I see:
Error detected while processing function <SNR>128_StartDebug[2]..<SNR>128_StartDebug_internal[45]..<SNR>128_StartDebug_term:
line 97:
Cannot check if your gdb works, continuing anyway
Press ENTER or type command to continue
Also for me increasing the limit doesn't seem to help.
I don't have NFS, everything is local, and this is on a very small sample program I'm using specifically for testing termdebug. My environment is a bit different:
- Version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jan 28 2021 17:26:13) Included patches: 1-814 Modified by Gentoo-8.2.0814-r100 - OS: Gentoo
- Terminal: x11-terms/rxvt-unicode-9.22-r8
What I have found is that after the error occurs and I press ENTER to continue, the gdb window opens with my cursor at the end of the last line here:
new-ui mi /dev/pts/21
File /usr/include/gcc/**/*.h will be skipped when stepping.
Reading symbols from ./target/debug/sandbox-gdb...
(gdb) new-ui mi /dev/pts/21
If I now immediately press ENTER, I'll get a "New UI allocated" message, and everything will then work perfectly:
new-ui mi /dev/pts/21
File /usr/include/gcc/**/*.h will be skipped when stepping.
Reading symbols from ./target/debug/sandbox-gdb...
(gdb) new-ui mi /dev/pts/21
New UI allocated
(gdb)
If I don't press enter here, and instead clear the line, the GDB window will work fine but vim won't be able to trace the execution. The PC and Breakpoint highlights won't be shown and I won't be able to set :Break from the source view.
Bram Moolenaar
> I have a similar problem, after running the Termdebug command I see:
> Error detected while processing function <SNR>128_StartDebug[2]..<SNR>128_StartDebug_internal[45]..<SNR>128_StartDebug_term:
> Cannot check if your gdb works, continuing anyway
> Press ENTER or type command to continue
>
> Also for me increasing the limit doesn't seem to help.
>
> I don't have NFS, everything is local, and this is on a very small sample program I'm using specifically for testing termdebug. My environment is a bit different:
>
> ```
> VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jan 28 2021 17:26:13)
> Included patches: 1-814
> Modified by Gentoo-8.2.0814-r100
> - OS: Gentoo
> - Terminal: x11-terms/rxvt-unicode-9.22-r8
>
> What I have found is that after the error occurs and I press ENTER to continue, the gdb window opens with my cursor at the end of the last line here:
> ```
> new-ui mi /dev/pts/21
> File /usr/include/gcc/**/*.h will be skipped when stepping.
> Reading symbols from ./target/debug/sandbox-gdb...
> (gdb) new-ui mi /dev/pts/21
> ```
>
> If I now immediately press ENTER, I'll get a "New UI allocated" message, and everything will then work perfectly:
> ```
> new-ui mi /dev/pts/21
> File /usr/include/gcc/**/*.h will be skipped when stepping.
> Reading symbols from ./target/debug/sandbox-gdb...
> (gdb) new-ui mi /dev/pts/21
> New UI allocated
> (gdb)
> ```
>
> If I don't press enter here, and instead clear the line, the GDB
> window will work fine but vim won't be able to trace the execution.
> The PC and Breakpoint highlights won't be shown and I won't be able to
> set :Break from the source view.
things?
First of all, enable logging by uncommenting the ch_logfile() line
(around line 125).
Now below "Set arguments to be run" add some delay to see if that makes
any difference:
sleep 100m
With different values, up to 1000m.
Another sleep could be used just before sending "new-ui".
Check the "debuglog" for any hints, especially where Vim is waiting for
the gdb response. You can add more ch_log() calls if needed.
--
MAN: You don't frighten us, English pig-dog! Go and boil your bottoms,
son of a silly person. I blow my nose on you, so-called Arthur-king,
you and your silly English K...kaniggets.
He puts hands to his ears and blows a raspberry.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// 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 ///
Daniel Nelson
If I add sleep 200m after "Set arguments to be run" then it is enough to mask the race condition and everything works. I am attaching the debug log before any changes and a copy after the added sleep statement.
Uri Moszkowicz
enough. Log file attached. Thanks!
On Fri, May 14, 2021 at 1:49 PM Daniel Nelson ***@***.***>
wrote:
> If I add sleep 200m after "Set arguments to be run" then it is enough to
> mask the race condition and everything works. I am attaching the debug log before
> and a copy after
> <https://github.com/vim/vim/files/6480658/debuglog-with-sleep.txt> the
> added sleep statement.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABNJJQROWUBNCZMMPIZL4K3TNVWCXANCNFSM435BRS3A>
> .
Bram Moolenaar
Where exactly did you put that sleep? I guess it is:
" Set arguments to be run. First wait a bit to make detecting gdb a bit
" more reliable.
sleep 200m
if len(proc_args)
call term_sendkeys(s:gdbbuf, 'set args ' . join(proc_args) . "\r")
endif
Daniel Nelson
Yes, that is exactly what I did.
Uri Moszkowicz
On Sat, May 15, 2021 at 5:28 AM Bram Moolenaar ***@***.***>
wrote:
> Where exactly did you put that sleep? I guess it is:
>
> " Set arguments to be run. First wait a bit to make detecting gdb a bit
> " more reliable.
> sleep 200m
> if len(proc_args)
> call term_sendkeys(s:gdbbuf, 'set args ' . join(proc_args) . "\r")
> endif
>
> —
> Reply to this email directly, view it on GitHub
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABNJJQWOPXBBNURIUVKEDOLTNZEDRANCNFSM435BRS3A>
> .
Bram Moolenaar
> That's what I did, except I needed a larger value
delay is likely to help most people, and 200 msec is small enough not to
be noticed.
--
Facepalm statement #2: "If there is a country without immigrants I'm going to
move there"
/// 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 ///
—
Daniel Nelson
I was thinking that perhaps we could read the (gdb) prompt before sending commands, but one problem I anticipate with this is it would probably break if the prompt was customized. Another idea is to start gdb with an echo command, and then maybe we could try to read the text:
$ gdb -quiet --eval-command 'echo howdy\n'
File /usr/include/gcc/**/*.h will be skipped when stepping.
howdy
(gdb)
This made me wonder, could we just send all the setup commands as part of the gdb exec command? I haven't tried to get this working at all, but do you see any immediately obvious problems with it?
Bram Moolenaar
> I was thinking that perhaps we could read the `(gdb)` prompt before
> sending commands, but one problem I anticipate with this is it would
> probably break if the prompt was customized. Another idea is to start
> gdb with an echo command, and then maybe we could try to read the
> text:
> ```
> $ gdb -quiet --eval-command 'echo howdy\n'
> File /usr/include/gcc/**/*.h will be skipped when stepping.
> howdy
> (gdb)
It looks like this works. We still need a timeout in case reading
symbols takes a long time. Perhaps five seconds would be sufficient?
I'll use this a little while and send it out later.
> This made me wonder, could we just send all the setup commands as part
> of the gdb exec command? I haven't tried to get this working at all,
> but do you see any immediately obvious problems with it?
of gdb floating around, if it works with one it doesn't mean it works
everywhere.
--
FATHER: Make sure the Prince doesn't leave this room until I come and
get him.
FIRST GUARD: Not ... to leave the room ... even if you come and get him.
FATHER: No. Until I come and get him.
SECOND GUARD: Hic.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Christian Brabandt
looks like this has been included as of d2ea7cf so closing
Christian Brabandt
Closed #8163.