[vim/vim] cannot execute interactive Ex commands (#7891)

[lacygoill]

I have a weird bug since a few weeks, and I can't find a minimal example.

The first thing wrong which I notice is that I can't move my cursor anymore by pressing j or k. I think that's because they are mapped to expressions using the <expr> argument. I think all <expr> mappings (and abbreviations) get broken.

The second thing wrong is my statusline. Suddenly, it doesn't display any useful information; just this:

statusline#main()

That's because I set the 'statusline' option with this value:

set stl=%!statusline#main()

The third thing wrong is that any interactive Ex command is ignored. For example, if I type :, q, a, ! and Enter, nothing happens. Vim doesn't quit.

When Vim is in this weird state, there's 1 thing which helps: pressing C-k. That's because the latter is mapped – without <expr> – like this:

nno <c-k> <cmd>call window#navigate('k')<cr>

Basically, this mapping executes wincmd k which focuses the window right above. When I use this mapping, everything gets temporarily fixed. But these issues can re-appear quickly. For example, if I interactively execute an invalid command, Vim gets broken again:

:invalid

In particular, the command is not executed. It's only after pressing C-k (and probably any mapping which doesn't use <expr>), that the command seems to be executed, and an error message gets printed. Then, Vim is temporarily fixed again.

I suspect the issue is a regression in one of these 2 parts of the codebase:

• Vim9 script (because all my config is in Vim9 script)
• the FocusGained and FocusLost events

Regarding the last bullet point, most of the time (if not all the time), the issue starts after I focus another program window (e.g. web browser), then focus back the Vim terminal. Also, these events have been implemented recently; a few weeks ago:

• 8.2.2345 no focus events in a terminal
• 8.2.2348 no check for modified files after focus gained
• 8.2.2352 if focus lost/gained is received twice code is not ignored
• 8.2.2383 focus escape sequences are not named
• 8.2.2428 FocusGained does not work when 'ttymouse' is empty

The timeline could match the start of my issue.

This is really annoying, and I can't find a minimal example, because the issue usually starts after a few hours of using Vim. That's way too long to reduce my config. I've tried to log the channel activity:

call ch_logfile('logfile', 'w')

To find whether I was executing something special, right before the issue starts. But nothing stands out. The last time, I had just executed :ve to see my Vim version, then focused the web browser, then focused back Vim.

I've also tried to log all executed Ex commands:

:set vfile=/tmp/logfile

:set verbose=16

But Vim is not really usable on a long period of time in that state; even though the messages are logged into a file, it creates many extra issues (wrong syntax highligting, unexpected displayed messages, big lag when entering insert mode, ...).

Note that the previous log has been edited to only keep the keypresses. If it helps, I could try to get another log which is not edited. Aside from that, what else can I do to gather more information? I can't run valgrind on a long period of time.

I'm on Vim 8.2.2539. I can't go beyond because #7887 creates too many issues. The OS is Ubuntu 16.04, and the terminal is st inside tmux.

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

[lacygoill]

I forgot to mention that I don't use FocusGained nor FocusLost. Also, the issue is not caused by an autocmd. A few days ago, while Vim was in this weird state, I deleted all the autocmds. It didn't help.

[lacygoill]

Next time it happens, I'll do this:

• press C-k to temporarily fix Vim
• run :set vfile=/tmp/logfile verbose=20 to log as much info as possible
• run :invalid to break Vim again
• run :qa! to try to quit Vim

Hopefully, the logfile will explain why Vim doesn't quit. If it doesn't, it would be help if someone could provide some patch to make Vim give more info, so that it explains why it ignores any interactive Ex command while in this weird state.

[lacygoill]

Alternatively, I could try to attach valgrind to the running Vim process when the issue arises. But there are 2 issues:

• I never did this (although google could help)
• I can't run valgrind on Ubuntu 16.04

Regarding the last bullet point, valgrind aborts with this message:

==14167== Memcheck, a memory error detector
==14167== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==14167== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==14167== Command: ./src/vim -Nu NONE
==14167== Parent PID: 13719
==14167== 

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:  
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strlen
valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:  
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:  
valgrind:    On Debian, Ubuntu:                 libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind:  
valgrind:  Cannot continue -- exiting now.  Sorry.

The message suggests to install the package libc6-dbg; which I did a long time ago. It never helped.

[Christian Brabandt]

If you suspect this is related to FocusGained/FocusLost, try adding those events to the 'eventignore' setting and see if this helps narrowing down the problem.

[Dominique Pellé]

@lacygoill wrote:

==14167== Memcheck, a memory error detector
==14167== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==14167== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==14167== Command: ./src/vim -Nu NONE
==14167== Parent PID: 13719
==14167== 

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:

Your version of valgrind looks old. No idea if this will help, but consider
building valgrind yourself from the latest in git:

$ git clone git://sourceware.org/git/valgrind.git
$ cd valgrind
$ ./autogen.sh
$ ./configure
$ make -j8
$ sudo make install

The latest valgrind (snapshot from main branch) should then be installed in /usr/local/bin/.

$ valgrind --version
valgrind-3.17.0.GIT

[bfrg]

Vim9 script (because all my config is in Vim9 script)

Last time I tried to port my 'statusline' function to vim9script it didn't work. Is this even supported yet? There's still a todo item to compile options that are an expression, see :help todo. Since statusline is not explicitly listed there I assumed that it was just forgotten since it didn't work at that time. Have you tried it with the default statusline, or rolling your statusline#main() function back to legacy vimscript?

[Bram Moolenaar]

> Next time it happens, I'll do this:
>

> - press `C-k` to temporarily fix Vim
> - run `:set vfile=/tmp/logfile verbose=20` to log as much info as possible
> - run `:invalid` to break Vim again
> - run `:qa!` to try to quit Vim

>
> Hopefully, the logfile will explain why Vim doesn't quit. If it
> doesn't, it would be help if someone could provide some patch to make
> Vim give more info, so that it explains why it ignores any interactive
> Ex command while in this weird state.

You can also use:

call ch_logfile('logfile', 'w')

The output may contain hints, esp. when using channels.

Another way is to compile for debugging with the "-g" flag, do not use
"-O2" or strip the executable. Then you should be able to attach to the
running Vim from gdb and step through the code. You can attach with:
gdb ./vim {processnr}

Instead of "./vim" use the path to the compiled vim executable.

--
John: When I'm playing tennis with friends I always get carried away
George: You hurt your foot each time?

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

[lacygoill]

If you suspect this is related to FocusGained/FocusLost, try adding those events to the 'eventignore' setting and see if this helps narrowing down the problem.

Good idea. I've just written this in my vimrc:

&ei = 'FocusGained,FocusLost'

Let's see if it fixes the issue.

---

Your version of valgrind looks old. No idea if this will help, but consider building valgrind yourself from the latest in git:

Oh, nice. It worked. Now, I have a recent valgrind:

$ valgrind --version
valgrind-3.17.0.GIT

I will never have to start a VM again. Thank you very much.

---

Last time I tried to port my 'statusline' function to vim9script it didn't work. Is this even supported yet? There's still a todo item to compile options that are an expression, see :help todo. Since statusline is not explicitly listed there I assumed that it was just forgotten since it didn't work at that time. Have you tried it with the default statusline, or rolling your statusline#main() function back to legacy vimscript?

I assume you're referring to this item:

• compile options that are an expression, e.g. "expr:" in 'spellsuggest',
  'foldexpr', 'foldtext', 'printexpr', 'diffexpr', 'patchexpr', 'charconvert',
  'balloonexpr', 'includeexpr', 'indentexpr', 'formatexpr'.
  Give an error if compilation fails. (#7625)
  Use the location where the option was set for deciding whether it's to be
  evaluated in Vim9 script context.

I don't think it applies to the 'statusline' option. This is for options whose value is a Vim expression. These expressions should be compiled for various reasons; a better efficiency being one of them. You could argue that with 'statusline', the value can be a Vim expression:

set stl=%!Func()

That's true, but you can write Func() as a :def function; in which case, it's necessarily compiled.

In any case, that's one of the first plugins that I refactored in Vim9 script, and it has always worked fine; except for this issue which was fixed in 8.2.1437.

The only thing missing is :lockvar inside a :def function, which forces me to still keep 2 legacy functions. But it's on the todo list:

• Implement :lockvar and :unlockvar. How about local variables? Perhaps only
  allow this for global variables. Use :final or :const otherwise.

---

You can also use:

call ch_logfile('logfile', 'w')

The output may contain hints, esp. when using channels.

OK, I'm running it automatically on startup from now on.

Another way is to compile for debugging with the "-g" flag, do not use
"-O2" or strip the executable.

OK, I've edited my script to automatically enable the debugging symbols and disable the optimizations:

sed -i 's/#CFLAGS = -g$/CFLAGS = -g -O0/ ; s@#STRIP = /bin/true@STRIP = /bin/true@' src/Makefile

Then you should be able to attach to the
running Vim from gdb and step through the code.
You can attach with:
gdb ./vim {processnr}

Instead of "./vim" use the path to the compiled vim executable.

I'll do it. However, I'm not sure which gdb commands I should execute then. The only ones that I know are:

(gdb) set logging on
(gdb) backtrace

There is also the p command to print expressions. But I don't know which expression(s) I should ask for.

[lacygoill]

I'm closing because I can't reproduce anymore. If it re-appears I'll try to get a backtrace from gdb.

[lacygoill]

Closed #7891.