[vim/vim] Termdebug no extra highlighting and no :Break (#2154)

[Boris Staletic]

I have just compiled latest vim (8.0.1144 at this moment), wishing to try :Termdebug.

Unfortunately, vim had no special highlighting for the breakpoints or the current line at which is the debugger. Nor ddi commands :Break, :Step, :Next, :Continue, :Finish and :Eval looked like they are doing anything.

It would also be nice if vim could keep track and automatically open the file containing the line at which gdb currently is, but that's a separate issue.

What I tried:

• Open a.c
• :Termdebug
• Inside gdb - file a.out
• Try :Break and others.

What happened:

Vim did sucesfully open the two windows and I could debug the code, but I didn't have a highllighted line nor did :Break and similar work.

Output of :version:

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Sep 25 2017 04:07:53)
Included patches: 1-1144
Modified by Gentoo-9999
Compiled by portage@gentoo
Huge version without GUI.  Features included (+) or not (-):
+acl             +cmdline_hist    -ebcdic          +gettext         +listcmds        +mouse_sgr       +persistent_undo +smartindent     +termresponse    +wildignore
+arabic          +cmdline_info    +emacs_tags      -hangul_input    +localmap        -mouse_sysmouse  +postscript      +startuptime     +textobjects     +wildmenu
+autocmd         +comments        +eval            +iconv           -lua             +mouse_urxvt     +printer         +statusline      +timers          +windows
-balloon_eval    +conceal         +ex_extra        +insert_expand   +menu            +mouse_xterm     +profile         -sun_workshop    +title           +writebackup
-browse          +cryptv          +extra_search    +job             +mksession       +multi_byte      -python          +syntax          -toolbar         +X11
++builtin_terms  -cscope          +farsi           +jumplist        +modify_fname    +multi_lang      +python3         +tag_binary      +user_commands   +xfontset
+byte_offset     +cursorbind      +file_in_path    +keymap          +mouse           -mzscheme        +quickfix        +tag_old_static  +vertsplit       -xim
+channel         +cursorshape     +find_in_path    +lambda          -mouseshape      +netbeans_intg   +reltime         -tag_any_white   +virtualedit     -xpm
+cindent         +dialog_con      +float           +langmap         +mouse_dec       +num64           +rightleft       -tcl             +visual          +xsmp_interact
+clientserver    +diff            +folding         +libcall         -mouse_gpm       +packages        -ruby            +termguicolors   +visualextra     +xterm_clipboard
+clipboard       +digraphs        -footer          +linebreak       -mouse_jsbterm   +path_extra      +scrollbind      +terminal        +viminfo         -xterm_save
+cmdline_compl   -dnd             +fork()          +lispindent      +mouse_netterm   -perl            +signs           +terminfo        +vreplace        
   system vimrc file: "/etc/vim/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: x86_64-pc-linux-gnu-gcc -c -I. -Iproto -DHAVE_CONFIG_H     -march=native -O2 -pipe -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1       
Linking: x86_64-pc-linux-gnu-gcc   -Wl,-O1 -L/usr/local/lib -Wl,--as-needed -o vim    -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE  -lm -lncurses -lelf -lnsl   -lacl -lattr -ldl     -L/usr/lib64/python3.5/config-3.5m -lpython3.5m -lpthread -ldl -lutil -lm      

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub

[Bram Moolenaar]

Boris Staletic wrote:

> I have just compiled latest vim (8.0.1144 at this moment), wishing to

> try `:Termdebug`.

>
> Unfortunately, vim had no special highlighting for the breakpoints or

> the current line at which is the debugger. Nor ddi commands `:Break`,
> `:Step`, `:Next`, `:Continue`, `:Finish` and `:Eval` looked like they

> are doing anything.
>
> It would also be nice if vim could keep track and automatically open
> the file containing the line at which gdb currently is, but that's a
> separate issue.
>
> What I tried:
>

> - Open `a.c`
> - `:Termdebug`
> - Inside gdb - `file a.out`
> - Try `:Break` and others.

>
> What happened:
>
> Vim did sucesfully open the two windows and I could debug the code,
> but I didn't have a highllighted line nor did `:Break` and similar
> work.

Not sure why this doesn't work for you. I just wrote an example
session, please try it out:

Start in the Vim "src" directory and build Vim: >
% make
Start Vim: >
% ./vim
Load the termdebug plugin and start debugging Vim: >
:packadd termdebug
:Termdebug vim
You should now have three windows:
source - where you started, has a window toolbar with buttons
gdb - you can type gdb commands here
program - the executed program will use this window
You can use CTRL-W CTRL-W or the mouse to move focus between windows.
Put focus on the gdb window and type: >
break ex_help
run
Vim will start running in the program window. Put focus there and type: >
:help gui
Gdb will run into the ex_help breakpoint. The source window now shows the
ex_cmds.c file. A ">>" marker will appear where the breakpoint was set. The
line where the debugger stopped is highlighted. You can now step through the
program. Let's use the mouse: click on the "Next" button in the window
toolbar. You will see the highlighting move as the debugger executes a line
of source code.

Click "Next" a few times until the for loop is highlighted. Put the cursor on
the end of "eap->arg", then click "Eval" in the toolbar. You will see this
displayed:
"eap->arg": 0x555555e68855 "gui" ~
This way you can inspect the value of local variables. You can also focus the
gdb window and use a "print" command, e.g.: >
print *eap

Now go back to the source window and put the cursor on the first line after
the for loop, then type: >
:Break
You will see a ">>" marker appear, this indicates the new breakpoint. Now
click "Cont" in the toolbar and the code until the breakpoint will be
executed.

You can type more advanced commands in the gdb window. For example, type: >
watch curbuf
Now click "Cont" in the toolbar (or type "cont" in the gdb window). Execution
will now continue until the value of "curbuf" changes, which is in do_ecmd().
To remove this watchpoint again type in the gdb window: >
delete 3

You can see the stack by typing in the gdb window: >
where
Move through the stack frames, e.g. with: >
frame 3
The source window will show the code, at the point where the call was made to
a deeper level.


--
$ echo pizza > /dev/oven

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Boris Staletic]

@brammool Thanks for taking your time to look into this. I'm compiling vim right now and will try the exact procedure you have posted.

[Boris Staletic]

After issuing ./vim to start vim from the build dir I get the following errors:

Error detected while processing /home/bstaletic/.vim/vimrc:
line   14:
E484: Can't open file /usr/local/share/vim/syntax/syntax.vim
Error detected while processing /home/bstaletic/.vim/pack/bundle/start/distinguished/colors/distinguished.vim:
line    5:
E254: Cannot allocate color Grey50
line    7:
E254: Cannot allocate color Grey50
Error detected while processing /home/bstaletic/.vim/vimrc:
line   31:
E919: Directory not found in 'packpath': "pack/*/opt/matchit"
line   32:
E919: Directory not found in 'packpath': "pack/*/opt/termdebug"
YouCompleteMe unavailable: requires Vim compiled with Python (2.6+ or 3.3+) support.
UltiSnips requires py >= 2.7 or py3
Press ENTER or type command to continue

Should I pass something to vim so it knows where to look for the termdebug?

[Boris Staletic]

And if I use my system vim after invoking :Termdebug vim, gdb and program buffers work, but the source buffer is as useful as any other vim instance would be, i.e. the buffer doesn't track the debugger line and clicking onto Step at the top of the window does absolutely nothing.

[Bram Moolenaar]

Boris Staletic wrote:

> After issuing `./vim` to start vim from the build dir I get the following errors:
> ```
> Error detected while processing /home/bstaletic/.vim/vimrc:
> line 14:
> E484: Can't open file /usr/local/share/vim/syntax/syntax.vim
> Error detected while processing /home/bstaletic/.vim/pack/bundle/start/distinguished/colors/distinguished.vim:
> line 5:
> E254: Cannot allocate color Grey50
> line 7:
> E254: Cannot allocate color Grey50
> Error detected while processing /home/bstaletic/.vim/vimrc:
> line 31:
> E919: Directory not found in 'packpath': "pack/*/opt/matchit"
> line 32:
> E919: Directory not found in 'packpath': "pack/*/opt/termdebug"
> YouCompleteMe unavailable: requires Vim compiled with Python (2.6+ or 3.3+) support.
> UltiSnips requires py >= 2.7 or py3
> Press ENTER or type command to continue
> ```
>
> Should I pass something to vim so it knows where to look for the termdebug?

If you haven't installed Vim yet, tell it to use the runtime directory
next to your sources:
csh: setenv VIMRUNTIME ../runtime
sh: export VIMRUNTIME=../runtime

Use the full path to avoid problems.

--
hundred-and-one symptoms of being an internet addict:
205. You're constantly yelling at your spouse, family, roommate, whatever,
for using the phone for stupid things...like talking.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

[Boris Staletic]

So, after export VIMRUNTIME=/home/bstaletic/Temp/vim/runtime and following the procedure above:

• Things that work:
  • Termdebug pacakge is loaded and running.
  • Program and gdb buffers are working properly.
  • Mouse is able to click on Step and others at the top of the source window.
• Things that don't work:
  • Source buffer is empty.
  • After a click on Step vim does write in thte status line Step, but nothing more (i.e. It is obviously being issued from the command line, but nothing actually happens.)

[Boris Staletic]

I tried creating a new linux user with bash as its shell and no config inside $HOME. The behaviour remained the same.

Then I decided to install xterm and try with my test user. To my surprise this worked.
So then I tried to run xterm with my regular user and my full vim configuration. This again worked.

Conclusion: This is an incompatibility between st and vim.

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or mute the thread.

[Boris Staletic]

Well, it's not only st that is affected. RXvt-unicode is also unable to work with Termdebug.

[Boris Staletic]

I managed to find out what breaks the plugin.

If the font used is sufficiently large, Termdebug won't work.

With st and font xos4 Terminus:size=16 the plugin stopped working. Stepping down to size=14 made the plugin work again.

With xterm plugin stopped working after increasing the font size to 22.

NOTE: Even though font size 16 and 22 are very different, they looked about the same in these two terminal emulators.

[Bram Moolenaar]

Boris Staletic wrote:

> I managed to find out what breaks the plugin.
>
> If the font used is sufficiently large, `Termdebug` won't work.
>
> With `st` and font `xos4 Terminus:size=16` the plugin stopped working. Stepping down to `size=14` made the plugin work again.
>
> With `xterm` plugin stopped working after increasing the font size to 22.
>
> NOTE: Even though font size 16 and 22 are very different, they looked about the same in these two terminal emulators.

That is weird. Vim has no awareness of the font used in a terminal.
Only the window size matters. Perhaps you can make it work or break it
by resizing the window?

--
hundred-and-one symptoms of being an internet addict:

213. Your kids start referring to you as "that guy in front of the monitor."

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

[Boris Staletic]

I've just tried making the plugin stop working by making each of the three windows occupy an absurdly small amount of screen space. Since the problem arises when the font is larger than somevalue, I assumed making the windows smaller would be the right direction.

But I couldn't break it by resizing the windows with st and font size of 14. Nor could I make it work the same way once I increased the font size to 16.

[Marius Gedminas]

For the record, I can reproduce this in gnome-terminal. Blank source window, :Step doesn't do anything.

[Boris Staletic]

I am currently trying to debug this further.

New information I got:
When the font is big enough, out_cb of the hidden terminal which is used to communicate with gdb is never called.

For clarification:

	" Create a hidden terminal window to communicate with gdb
	let s:commbuf = term_start('NONE', {
				\ 'term_name': 'gdb communication',
				\ 'out_cb': function('s:CommOutput'),    " Never called if font is too big
				\ 'hidden': 1,
				\ })

[Boris Staletic]

I forgot to mention, if the terminal is not hidden the callback is called.

[Boris Staletic]

I've just tried :termdebug on mint with ppa:jonathonf/vim and it does not work, showing the same issues as mentioned in the first post.

There's one difference though. Font size doesn't affect the issue.

[Christian Brabandt]

I wonder, if this is caused by the initialization message. I can reproduce this when using a window, in which the gdb init message (which is 15 lines long) and stops with
---Type <return> to continue, or q <return> to quit---
if there is not enough space in the current window. I think, gdb does not read the other gdb commands, until Enter has been pressed, which keeps the window empty.

It looks like, using -quiet as argument will skip the initialization message and should fix that problem:

diff --git a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
index 28d5a9b46..f16110b5f 100644
--- a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
+++ b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
@@ -80,7 +80,7 @@ func s:StartDebug(cmd)
   let commpty = job_info(term_getjob(s:commbuf))['tty_out']

   " Open a terminal window to run the debugger.
-  let cmd = [g:termdebugger, '-tty', pty, a:cmd]
+  let cmd = [g:termdebugger, '-quiet', '-tty', pty, a:cmd]
   echomsg 'executing "' . join(cmd) . '"'
   let gdbbuf = term_start(cmd, {
        \ 'exit_cb': function('s:EndDebug'),

[Boris Staletic]

Shrinking down the terminal on mint reproduces the original bug. Applying @chrisbra's patch seems to fix the problem. I'll test on Gentoo later tonight.

>```
>
>--
>You are receiving this because you authored the thread.
>Reply to this email directly or view it on GitHub:
>https://github.com/vim/vim/issues/2154#issuecomment-338663678

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[rith-iqlect]

When I use the term debug as suggested by @brammool , I get the following error:
"undefined command : "new-ui". Try help.
Attached is the screenshot. Could you please tell me If I did something wrong?

[Boris Staletic]

That's because your gdb is not a recent enough version to support `new-ui`.

On October 29, 2017 10:17:42 AM GMT+01:00, rith-iqlect <notifi...@github.com> wrote:
>When I use the term debug as suggested by @brammool , I get the
>following error:
>"undefined command : "new-ui". Try help.
>Attached is the screenshot. Could you please tell me If I did something
>wrong?

>

>
>
>--
>You are receiving this because you authored the thread.
>Reply to this email directly or view it on GitHub:

>https://github.com/vim/vim/issues/2154#issuecomment-340247829

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

—

[Christian Brabandt]

you need at least version gdb 7.12. older versions do not support the new-ui command

[Bram Moolenaar]

Closed #2154 via c363251.