Re-opening search buffer crashes Vim

[rknLA]

Mac OS 10.11.6, iTerm 2 (3.0.15), vim 7.3

1. Open vim with a file buffer (vim foo.py)
2. Activate Command-T via remaped keys
3. Type a path and open a file
4. Use the :b command to switch buffers to the discarded Command T buffer (in this case, :b2)
5. Type something in the newly-reopened buffer.

This reliably causes vim to completely hang and rail the CPU (iTerm kindly acknowledges that "The bell is ringing a lot"). The only way out is to close the iTerm tab (or window) with vim still running, and then to Force Quit vim from the Activity Monitor.

[wincent]

Thanks for the report. I can't repro this exactly. When I get to step 4, I have to use :ls! to see unlisted/hidden buffers (because the Command-T window is unlisted/hidden), and then switch to that (in the case of my trial run, it was :b9), but it doesn't hang. It does print this error though on input:

Error detected while processing function commandt#private#HandleKey:
line    1:
Vim::DeletedWindowError: attempt to refer to deleted window

What version of Command-T are you running? I'm on current next branch, and a much newer version of Vim (8.0 with patches 1-535).

I think you're definitely running into an edge case, but it would still be desirable to tweak Command-T to make it bullet-proof against it.

[rknLA]

I forgot to check what version was running at work today, but will make a note to do this when I'm back at that computer on Tuesday.

The unlisted/hidden buffers don't show up in a normal :ls, but if I start vim with a file, and then open everything else with Command-T, then my listed buffers are all odd numbers, making mishaps easier than they should be.

I suppose it may also be time for me to upgrade vim...

[rknLA]

The version generating the error is ce9daf8.

Although, now, of course when I try to reproduce the issue, I can't either. I'm not totally sure what special cases need to be there to make it happen again, but it happened enough that I did manage to figure out the steps to reproduce the first time :\

[alfred-sa]

Hello, I have the same issue when working with multiple tabs :

• Open 2 files in vim
• Create a new tab (:tabnew)
• Randomly try to Command-T

There is only the 2 files in my current working directory.

I get this error :

/etc/vim/vim/bundle/command-t/ruby/command-t/lib/command-t/match_window.rb:79:in initialize' /etc/vim/vim/bundle/command-t/ruby/command-t/lib/command-t/controller.rb:366:innew' /etc/vim/vim/bundle/command-t/ruby/command-t/lib/command-t/controller.rb:366:in show' /etc/vim/vim/bundle/command-t/ruby/command-t/lib/command-t/controller.rb:147:inshow_file_finder' Erreur détectée en traitant function commandt#FileFinder : ligne 2 : RuntimeError: Can't re-open Command-T match listing buffer

And a couple Command-T later, vim hangs and uses 100% CPU.

My Command-T version : commit 29f2606a9665058a98b56f2d8062ba614a3f246e (HEAD -> master, origin/master, origin/HEAD) Author: Greg Hurrell greg@hurrell.net Date: Fri Jun 23 07:38:15 2017 -0700

Prefer longer, more explicit command names

My vim version : VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Aug 15 2017 02:41:29)

Hope it helps.

[wincent]

@whuji: I'm afraid these instructions are not specific enough for me to repro the issue:

• Open 2 files in vim
• Create a new tab (:tabnew)
• Randomly try to Command-T

How do you open the 2 files? In splits? Is 'hidden' set?

What does "Randomly try" mean?

I did my best to do the above and saw no errors.

I'd obviously like to figure out what is going on, but will need more precise instructions, information about what version of Vim you are using, and probably also a minimal ~/.vimrc that manifests the issue, as it may be settings-dependent.

Going to close this in any case as your issue sounds different from the original report; please feel welcome to open a new issue with more details and we can continue the discussion there.

[Barricade]

Same error because of the following line in my .vimrc: autocmd BufWinEnter * nested if (expand('%:p')[:len(getcwd()) - 1] == getcwd() && !exists('b:NERDTree')) | NERDTreeFind | wincmd p | endif If I remove wincmd p from it, it works. Why does it fail with this?

[wincent]

@Barricade: I am not sure what you're seeing is the same as the original issue (which was about a crash). If I use your autocmd I see RuntimeError: Can't re-open Command-T match listing buffer, but not a crash.

As to why this would happen, I do know NERDTree does some pretty crazy jumping around between buffer (based on my experience participating in this issue: https://github.com/preservim/nerdtree/issues/684).