Crash when new tags file loaded while waiting for tag selection

[Benjamin Fritz]

The attached test_vimrc.vim sets up a command that (on Windows)

generates  a tags file asynchronously and then calls back into Vim using

--remote-expr to add that tags file to the 'tags' option.

The test_vimrc.vim also sets the 'cscopetag' option to enable selecting

between multiple tag matches.

After sourcing this test file, I can reliably make Vim crash as follows

(edit the "let ctags_exec" line to match your own exuberant ctags path):

1. cd to a project top-level directory with at least one large code

   subdirectory following C/C++ coding practices of having function

   declarations separate from function definitions.

2. Execute the :Ctags command and wait for it to finish

3. cd into the large code subdirectory and edit a code file

4. Go to a function call within the code file

5. Execute the :Ctags command again, but don't wait for it to finish

6. Before the tags processing completes, use CTRL-] to select the tag

   for the function your cursor is on (presumably, you will have 2

   matches, one for the function prototype and one for the function

   definition)

7. Wait for the :Ctags command to finish

8. Try entering a number to select the tag to jump to

9. Vim crashes

I'm using gvim 7.4.629 64-bit on Windows 7. I do have a couple custom

patches applied but nothing affecting tags processing.

[Bram Moolenaar]

Are you able to get a stack trace of the crash? Or even better, have it
crash in a debugger?

--
A poem: read aloud:

<> !*''# Waka waka bang splat tick tick hash,
^"`$$- Caret quote back-tick dollar dollar dash,
!*=@$_ Bang splat equal at dollar under-score,
%*<> ~#4 Percent splat waka waka tilde number four,
&[]../ Ampersand bracket bracket dot dot slash,
|{,,SYSTEM HALTED Vertical-bar curly-bracket comma comma CRASH.

Fred Bremmer and Steve Kroese (Calvin College & Seminary of Grand Rapids, MI.)

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

[Ben Fritz]

On Friday, March 20, 2015 at 7:00:21 AM UTC-5, Bram Moolenaar wrote:
>
> Are you able to get a stack trace of the crash? Or even better, have it
> crash in a debugger?
>

Sure will!

...as soon as I can figure out how to force ctags to parse those stupid *.pro files along with the rest of the code. :-\

[Ben Fritz]

Figured that out, by adding --langmap=c:+.pro

Here's the backtrace from gdb in MinGW. I'll try to look into it some more tomorrow if someone else doesn't beat me to it:

(gdb) bt
#0 0x0054f080 in screen_puts_len (text=0x2b4480 "\"eval.pro\" ", textlen=11, row=-1, col=0, attr=0) at screen.c:7305
#1 0x004bcda6 in t_puts (t_col=0x22ec74, t_s=0x2b4480 "\"eval.pro\" ", s=0x2b448b "", attr=0) at message.c:2430
#2 0x004bc780 in msg_puts_display (str=0x2b4480 "\"eval.pro\" ", maxlen=11, attr=0, recurse=0) at message.c:2177
#3 0x004bc104 in msg_puts_attr_len (str=0x2b4480 "\"eval.pro\" ", maxlen=11, attr=0) at message.c:1936
#4 0x004bb4ce in msg_outtrans_len_attr (msgstr=0x2b4480 "\"eval.pro\" ", len=-1, attr=0) at message.c:1455
#5 0x004bb189 in msg_outtrans_attr (str=0x2b4480 "\"eval.pro\" ", attr=0) at message.c:1336
#6 0x00480976 in filemess (buf=0x3f4ca00, name=0x2b5bda8 "eval.pro", s=0x60a41d "", attr=0) at fileio.c:176
#7 0x00481853 in readfile ( fname=0x4381a48 "c:/Users/Ben/Code/vim-src/src/proto/eval.pro", sfname=0x2b5bda8 "eval.pro", from=0, lines_to_skip=0, lines_to_read=2147483647, eap=0x0, flags=1) at fileio.c:815
#8 0x004026e9 in open_buffer (read_stdin=0, eap=0x0, flags=0) at buffer.c:147
#9 0x00451c53 in do_ecmd (fnum=0, ffname=0x4381a00 "c:/Users/Ben/Code/vim-src/src/proto/eval.pro", sfname=0x437e410 "/Users/Ben/Code/vim-src/src/proto/eval.pro", eap=0x0, newlnum=0, flags=0, oldwin=0x2b5dd8) at ex_cmds.c:3694
#10 0x00451184 in getfile (fnum=0, ffname=0x3c1c880 "c:/Users/Ben/Code/vim-src/src/proto/eval.pro", sfname=0x437e410 "/Users/Ben/Code/vim-src/src/proto/eval.pro", setpm=1, lnum=0, forceit=0) at ex_cmds.c:3119
#11 0x00593866 in jumpto_tag ( lbuf=0x437d8a0 "\003/Users/Ben/Code/vim-src/tags", forceit=0, keep_help=1) at tag.c:3193
#12 0x005905eb in do_tag (tag=0x2b98264 "do_string_sub", type=9, count=0, forceit=0, verbose=0) at tag.c:1034
#13 0x005c2038 in do_cstag (eap=0x22f550) at if_cscope.c:304
#14 0x0046f647 in ex_tag_cmd (eap=0x22f550, name=0x607270 "tag") at ex_docmd.c:10338
#15 0x0046f59e in ex_tag (eap=0x22f550) at ex_docmd.c:10305
#16 0x004632fb in do_one_cmd (cmdlinep=0x22f9b4, sourcing=1, cstack=0x22f6b0, fgetline=0, cookie=0x0) at ex_docmd.c:2940
#17 0x0046055f in do_cmdline (cmdline=0x2bec1a8 "0ta do_string_sub", fgetline=0, cookie=0x0, flags=11) at ex_docmd.c:1133
#18 0x0045fda8 in do_cmdline_cmd (cmd=0x2bec1a8 "0ta do_string_sub") at ex_docmd.c:738
#19 0x004eb504 in nv_ident (cap=0x22fb00) at normal.c:5781
#20 0x004e366a in normal_cmd (oap=0x22fbc0, toplevel=1) at normal.c:1160
#21 0x0049e799 in main_loop (cmdwin=0, noexmode=0) at main.c:1334
#22 0x0049e1eb in VimMain (argc=1, argv=0x2b3418) at main.c:1034
#23 0x005e2023 in WinMain@16 (hInstance=0x400000, hPrevInst=0x0, lpszCmdLine=0xb325f0 "", nCmdShow=10) at os_w32exe.c:125
#24 0x005e8a7a in main ( argc=<error reading variable: Cannot access memory at address 0xb>, argv=<error reading variable: Cannot access memory at address 0xf>, __p__environ=<error reading variable: Cannot access memory at address 0x13>) at ../mingw/main.c:73

[Christian Brabandt]

Hi Ben!

On Fr, 20 Mär 2015, Ben Fritz wrote:

> On Friday, March 20, 2015 at 8:39:19 PM UTC-5, Ben Fritz wrote:
> > On Friday, March 20, 2015 at 7:00:21 AM UTC-5, Bram Moolenaar wrote:
> > >
> > > Are you able to get a stack trace of the crash? Or even better, have it
> > > crash in a debugger?
> > >
> >
> > Sure will!
> >
> > ...as soon as I can figure out how to force ctags to parse those stupid *.pro files along with the rest of the code. :-\
>
> Figured that out, by adding --langmap=c:+.pro
>
> Here's the backtrace from gdb in MinGW. I'll try to look into it some more tomorrow if someone else doesn't beat me to it:
>
> (gdb) bt
> #0 0x0054f080 in screen_puts_len (text=0x2b4480 "\"eval.pro\" ", textlen=11, row=-1, col=0, attr=0) at screen.c:7305
> #1 0x004bcda6 in t_puts (t_col=0x22ec74, t_s=0x2b4480 "\"eval.pro\" ", s=0x2b448b "", attr=0) at message.c:2430

Hm, t_puts() call screen_puts_len with msg_row=-1. I don't think this
should happen.

You could check, why msg_row is negative (ie perhaps set a watchpoint
for msg_row so gdb will stop whenever msg_row gets changed).



Best,
Christian
--
Das Üble an den Minderwertigkeitskomplexen ist, daß die falschen
Leute sie haben.
-- Sir Alec Guiness

[Bram Moolenaar]

Can someone reproduce it and get a stack trace, so that we know where it
happens? Or a valgrind log, might be even better.


--
How To Keep A Healthy Level Of Insanity:
5. Put decaf in the coffee maker for 3 weeks. Once everyone has gotten
over their caffeine addictions, switch to espresso.

[Benjamin Fritz]

Did you need a different kind of stack trace than the gdb "bt" backtrace I provided?

[Bram Moolenaar]

Ah, that was a few days later. I don't spot anything in there that is a
hint about what is wrong. Perhaps a valgrind log would help.
Or someone who can look around with gdb about the variable values when
it crashes.

--
How To Keep A Healthy Level Of Insanity:

7. Finish all your sentences with "in accordance with the prophecy".