[vim] Add support for backtrace on vim debug sessions (#433)

Alberto Fanjul

unread,

Sep 27, 2015, 4:47:40 AM9/27/15

to vim/vim

Added commands

backtrace(b): Show backtrace and current level
up(u): Goes up in backtrace
down(d): Goes down in backtrace

to move around backtrace.

resolves albfan/vim#2

You can view, comment on, or merge this pull request online at:

https://github.com/vim/vim/pull/433

Commit Summary

Add support for backtrace on vim debug sessions

File Changes

Patch Links:

—
Reply to this email directly or view it on GitHub.

Bram Moolenaar

unread,

Sep 27, 2015, 8:25:55 AM9/27/15

to vim/vim

Alberto Fanjul wrote:

> Added commands
>
> - backtrace(b): Show backtrace and current level
> - up(u): Goes up in backtrace
> - down(d): Goes down in backtrace

>
> to move around backtrace.
>
> resolves albfan/vim#2

Sounds nice. Have some people tried it out yet?

--
hundred-and-one symptoms of being an internet addict:
21. Your dog has its own home page.

/// 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 ///

Alberto Fanjul

unread,

Sep 27, 2015, 11:00:04 AM9/27/15

to vim/vim

On my fork issue there's a complete test case (working). My plan is to use it on albfan/vim-breakpts to enhance backtrace view (working too, but without evaluation on different levels be cause of this).

I have compiled and test it manual y. Is there a test framework on project to check features?

Christian Brabandt

unread,

Sep 28, 2015, 10:29:04 AM9/28/15

to vim/vim

Is there a test framework on project to check features?

There are various tests in the testdir/ directory. I am not sure however, if testing the internal debugger will work. You could set up a breakpoint, show the backtrace and continue running the script and at the end store the :mess output.

I have 2 remarks:
1) The patch produces these warnings.

ex_cmds2.c: In function ‘do_debug’:
ex_cmds2.c:269:51: warning: pointer targets in passing argument 1 of ‘strdup’ differ in signedness [-Wpointer-sign]
                             char * frame = strdup(sourcing_name);
                                                   ^
In file included from os_unix.h:542:0,
                 from vim.h:282,
                 from ex_cmds2.c:14:
/usr/include/string.h:176:14: note: expected ‘const char *’ but argument is of type ‘char_u *’
 extern char *strdup (const char *__s)
              ^
ex_cmds2.c:270:37: warning: declaration of ‘p’ shadows a previous local [-Wshadow]
                             char *  p    = strtok(frame, "..");
                                     ^
ex_cmds2.c:95:13: warning: shadowed declaration is here [-Wshadow]
     char_u *p;
             ^

2) the backtrace looks very useful. I am not sure however how the up and down are supposed to behave. Pressing [u]p/[d]own will make the indicator in the backtrace move up, but the debugger will continue to work from the last level. Other than that, I haven't seen any other thing happening when pressing up/down. So could you please clarify, how it is supposed to work?

Alberto Fanjul

unread,

Sep 28, 2015, 1:55:28 PM9/28/15

to vim/vim

Maybe a test can be created based on debuggredy I will check existing test and see what can be automated.

I was sure there will be warnings about <sfile> split. I will correct them.

About this feature I will copy verbatim the test case on my fork albfan/vim#2

function Foo()
   let var1 = 5
   let var2 = call Bar(var1)
endfunction

function Bar(var)
    let var2 = 7
    return a:var + var2
endfunction

A desired debug session

:debug Foo()
>step
>next
>backtrace
  #0 function Foo()
  >1 function Bar()
>echo  var2
7
>echo var1
(undefined)
>up
>echo var1
5
>backtrace
  >0 function Foo()
  #1 function Bar()

see when you issue up, you are in the context of funccall_T.caller (one level up) so you can evaluate functions on up level to see why you get to that point in debug.

It's better to see it visually as albfan/vim-breakpts offers. You can navigate through call stack using ":BPDBacktrace" and if you have patch 7.4.879. I can implement an usage for up and down commands to been able to use :BPDLocals in current select stacktrace level (see you need to use my fork of vim because I don't know how to detect vim used will have up and down commands)

I will post the branch on albfan/vim-breakpts as soon as possible

Alberto Fanjul

unread,

Oct 4, 2015, 10:51:24 AM10/4/15

to vim/vim

I will add command arg for backtrace, so you can do

> backtrace 1

or relative

> b +1
> b -2

to use on plugin vim-breakpts.

I'm working on test for this too.

Alberto Fanjul

unread,

Oct 7, 2015, 7:31:37 PM10/7/15

to vim/vim

I have created a test with all new functionality. src/testdir/test108.in

I'm not sure about the format to show backtrace. Any suggestion is appreciated

Something not implemented is the "drop to frame" or "step back" functionality:

https://sourceware.org/gdb/current/onlinedocs/gdb/Reverse-Execution.html#Reverse-Execution

Let me know if that would be a desirable functionality. Seems affordable at this point.

Bram Moolenaar

unread,

Oct 13, 2015, 2:36:06 PM10/13/15

to vim/vim

Alberto Fanjul wrote:

> I have created a test with all new functionality. [src/testdir/test108.in](https://github.com/albfan/vim/blob/848f0b29c00a11dcac21cf6c7f80a5753642335f/src/testdir/test108.in)

>
> I'm not sure about the format to show backtrace. Any suggestion is
> appreciated

I would prefer to mimic what gdb is doing. Also, I would like to have
the "frame 3" command to navigate to a certain frame.

I always use "where" to see the backtrace, but it's not well documented,
I suppoes it's just me.

So we would have the commands:

:backtrace
:bt (same as :backtrace)
:frame N
:up [N]
:down [N]

> Something not implemented is the "drop to frame" or "step back" functionality:
>
> https://sourceware.org/gdb/current/onlinedocs/gdb/Reverse-Execution.html#Reverse-Execution
>
> Let me know if that would be a desirable functionality. Seems
> affordable at this point.

I consider that a very advanced feature, we can do without it.

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

35. Your husband tells you he's had the beard for 2 months.

/// 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 ///

—

Alberto Fanjul

unread,

Oct 15, 2015, 3:41:14 PM10/15/15

to vim/vim

Here is all implemented. Just a note about frame (there are collisions):

f issues file
fi[nish]
fr[ame]

I wil change frame layout to mimic gdb in no time

Tony Mechelynck

unread,

Oct 16, 2015, 12:02:14 AM10/16/15

to vim_dev, reply+00b1d198bb91b9944b8961f64e19457fe5307aa...@reply.github.com

On Thu, Oct 15, 2015 at 9:40 PM, Alberto Fanjul <vim-dev...@256bit.org> wrote:

Here is all implemented. Just a note about frame (there are collisions):

f issues file

fi[nish]

fr[ame]

I wil change frame layout to mimic gdb in no time

When several ex-commands start the same, one of them always takes priority (usually the one with the highest antiquity), here are two examples with many such:

:e[dit] :ea[rlier] :ec[ho] :echoe[rr] :echoh[l] :echom[sg] :echon :el[se] :elsei[f] :em[enu] :en[dif] :ene[w] :endf[unction] :endfo[r] :endt[ry] :endw[hile] :ex :exe[cute] :exi[t] :exu[sage]

:f[ile] :fin[d] :fina[lly] :fini[sh] :fir[st] :fix[del] :files :filet[ype] :fo[ld] :for :foldc[lose] :foldd[oopen] :folddoc[losed] :foldo[pen] :files :fu[nction]

…and in the case of :Next and :X (which start with an uppercase letter) the builtin command takes precedence over user-commands.

So since :f or :fi always meant :file and :fin meant :find, you need to use at least :fini for :finish, and for compatibility reasons if a new :frame command is defined it should, at most, be abbreviated to :fr

Best regards,

Tony.

Alberto Fanjul

unread,

Oct 18, 2015, 2:43:39 PM10/18/15

to vim/vim, vim-dev ML

Although that sound understandable, that is not the way debug works on vim. See before this proposal, f has no collisions and executes directly finish command:

albfan@bd249d9#diff-28790a430300cd187bda51bd6a014757L200

I have added frame as a @brammool suggestion, prior implementation do the frame command behaviour on backtrace command (with no debug command collisions), so at this point don't know really what command should take priority. This implementation see f as collisions between finish and frame and left to the command to be interpreted as no debug vim command, but after that fi or fr are recognized as indubitable debug command and executed.

I will implement this the way you want, but to me sounds reasonable to give priority to debug commands in a debug session, so I would prefer to leave it this way or better off directly choose finish issuing f as users would expect before this change.

Bram Moolenaar

unread,

Nov 24, 2015, 11:54:31 AM11/24/15

to vim/vim, vim-dev ML

Alberto Fanjul wrote:

> Although that sound understandable, that is not the way debug works on
> vim. See before this proposal, `f` has no collisions and executes
> directly `finish` command:
>

> https://github.com/albfan/vim/commit/bd249d9b3dc83174f910735d95f5eae49f48a133#diff-28790a430300cd187bda51bd6a014757L200

>
> I have added `frame` as a @brammool suggestion, prior implementation
> do the `frame` command behaviour on `backtrace` command (with no debug
> command collisions), so at this point don't know really what command
> should take priority. This implementation see `f` as collisions
> between `finish` and `frame` and left to the command to be interpreted
> as no debug vim command, but after that `fi` or `fr` are recognized as
> indubitable debug command and executed.
>
> I will implement this the way you want, but to me sounds reasonable to
> give priority to debug commands in a debug session, so I would prefer
> to leave it this way or better off directly choose `finish` issuing
> `f` as users would expect before this change.

When building with this patch there are many compiler warnings.
E.g. for using "char *" instead of "char_u *". Please fix them.

There are trailing spaces and other style problems. Please match with
the Vim style for C code.

There are declarations after statements, older compilers don't support
that.

New functions in ex_cmds2.c should be made static, they are local to the
file.

--
Never eat yellow snow.

/// 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 ///

—

Alberto Fanjul

unread,

Nov 24, 2015, 12:55:25 PM11/24/15

to vim/vim, vim-dev ML

I will fix in a while

Alberto Fanjul

unread,

Nov 25, 2015, 2:08:58 AM11/25/15

to vim/vim, vim-dev ML

declaration, char_u and trailing space are fixed.

I have rebased to tip and now there's some problem with test_tagcase

Alberto Fanjul

unread,

Dec 3, 2015, 2:10:27 AM12/3/15

to vim/vim, vim-dev ML

As expected test_tagcase should be modified on small builds.

60422e6

I have rebased and corrected all declarations after statements. @brammool any other warning or style issue?

Kenichi Ito

unread,

Dec 3, 2015, 2:23:16 AM12/3/15

to vim/vim, vim-dev ML

There are still compiler warnings with clang.
https://travis-ci.org/vim/vim/jobs/94578356#L742

Alberto Fanjul

unread,

Dec 3, 2015, 2:37:35 AM12/3/15

to vim/vim, vim-dev ML

Opps. That was char* before my change. I have fixed it. I will check throughly CI outputs

Alberto Fanjul

unread,

Dec 3, 2015, 3:52:14 AM12/3/15

to vim/vim, vim-dev ML

I can't find more warnings, but now test86 fails on appveyor. Really don't know why

Kenichi Ito

unread,

Dec 3, 2015, 4:14:48 AM12/3/15

to vim/vim, vim-dev ML

I can't find more warnings, but now test86 fails on appveyor. Really don't know why

test86 sometimes fails on appveyor, so could you restart build?

Alberto Fanjul

unread,

Dec 3, 2015, 7:24:39 AM12/3/15

to vim/vim, vim-dev ML

I just can launch a nuild on my account. Seems to be working

https://ci.appveyor.com/project/albfan/vim/history

Kenichi Ito

unread,

Dec 3, 2015, 7:32:12 AM12/3/15

to vim/vim, vim-dev ML

test86 sometimes fails on appveyor

This is another problem.
See the history.
https://ci.appveyor.com/project/chrisbra/vim/history

Alberto Fanjul

unread,

Dec 3, 2015, 3:12:12 PM12/3/15

to vim/vim, vim-dev ML

code rebased. now:

test_listlbr_utf8 FAILED

Feeling kind of beta tester.

Alberto Fanjul

unread,

Jan 2, 2016, 3:13:52 AM1/2/16

to vim/vim, vim-dev ML

As supossed, wait is the way to go. test suite has been revamped and now all test pass and coverage has increased.

Let me know if there's anything else to do or rework

Alberto Fanjul

unread,

Jan 10, 2016, 6:00:06 AM1/10/16

to vim/vim, vim-dev ML

I'm a profuse plugin developer, I find myself always tweaking vim plugins, and this feature is unvaluable to detect where a plugin goes wrong (or where some variable value comes from)

Is there anything else I can do to merge this PR?

Alberto Fanjul

unread,

Jan 10, 2016, 2:20:42 PM1/10/16

to vim/vim, vim-dev ML

I suppose coveralls fails on rebase. Is it a known issue?

Here is a arch linux AUR package to test this feaure

https://github.com/albfan/aur-vim

Bram Moolenaar

unread,

Jan 16, 2016, 9:41:26 AM1/16/16

to vim/vim, vim-dev ML

Closed #433 via f1f60f8.

Alberto Fanjul

unread,

Jan 30, 2016, 3:18:53 AM1/30/16

to vim/vim, vim-dev ML

I finally review your commit against my PR. Lot of lessons learned.

I tagged it for easy review:

albfan@backtrace-PR...albfan:backtrace-PR-merge

Reply all

Reply to author

Forward